I want to a web application that concerns Homomorphic Encryption. I am using Microsoft SEAL. I wanted to know if there is any way I could use this library in javascript function so that whenever a button is clicked the javascript function is executed on the user's browser and the encryption is carried out using Microsoft SEAL. I tried emscripten but the C++ code importing the library SEAL is not generating a wasm file. I have spent alot of time trying to find a solution but no luck. All the solutions available result in the code executed on the server. If anyone knows a way I can achieve this please guide me.
The help would be really highly appreciated. Thanks
Yes!
There is an open source library, node-seal, which is a nearly complete port of Microsoft SEAL to WebAssembly (WASM) and should be able to accommodate the majority of use-cases. It works with NodeJS and in modern browsers.
There is also a website, morfix.io, where you may test and experiment with it inside your browser. You may even generate working code using node-seal.
Full disclosure, I’m the author of node-seal and the web demo.
I realize a JavaScript library like jQuery that is specific to the HTML / DOM wouldn't work nor make sense in a Flash ActionScript application. But what about other JavaScript libraries? I was reading that ActionScript is a superset of JavaScript / ECMAScript which is what got me wondering.
If it wouldn't use JavaScript libraries "out of the box" could a JavaScript library be adapted relatively easily? Also, does ActionScript support XMLHttpRequest or have a rough equivalent?
The syntax is similar, so you may be able to compile some code snippets. JavaScript looks more like the old Actionscript 2 though.
It's not only jQuery, but most JavaScript libraries are used to interact with the user interface or doing some communication things in the background. If they weren't, you could probably replace them with a server side library for the same job.
Many APIs, like the ones used for input and output are very different. If you are thinking of a copy&paste approach to convert a library, you would need to recreate a lot of those APIs for it to work. For example, a library to draw something on a canvas: You would either need to recreate the canvas API to draw the canvas instructions in flash - or create a wrapper to make flash call the original API to draw it on a real canvas. Alternatively rewrite all those parts, which are likely to found almost everywhere in the library.
That leaves us with libraries that strictly use non-js specific stuff. Maybe encoding/decoding libraries or algorithm and math heavy libraries. Those libraries may can be converted more easily. It would be quite a lot of work to refactor them into maintainable code though (in the OOP based Actionscript 3 sense). Apart from some less changes in the syntax, it probably requires almost the same amount of work to port the library to any other language. Also, chances are, that those generic libraries already exist for Actionscript.
This is a very old question but I thought to give an up to date answer.
Adobe ceased updates to its flash browser plugin as of January 12, 2021.
There are now some libraries and/or browser plugins being developed to continue flash support.
One that has the option of loading a JavaScript library from a HTML script src tag is Ruffle. As of this date it support 70% ActionScript-1/2 and 5% ActionScript-3.
The developers claim they plan for full support of AS1, AS2 & AS3.
I have tested it myself and found it to work quite well for many SWF files containing AS-1/2. The only thing required is to adjust your server software (ie. Apache, IIS, etc.) to allow wasm file support.
Use the link titled "Self Hosted" to download the necessary files that you must host.
ref. https://ruffle.rs/#releases
Is it possible utilize javascript in the making of windows desktop applications.I use borland delphi and i need to use javascript in my grids.
Worm, I've written a complete solution for you. See the screenshot attached below ...
A basic summary of what I can give is this ... a component that allows you to execute javascript, call delphi from from javascript, and access javascript functions and objects once you connect a script.
Here is a link to an brief article I wrote describing what you can do with javascript. At the end of the article is a zip file containing the source code and a compiled example program you can use to test out whatever javascript you want to write.
AJAX is a technology commonly applied in web applications where javascript is being executed by the client. Such notions are very difficult to apply in desktop applications. You could use background threads to perform expensive tasks to avoid freezing the application and then update the UI with the results of this background tasks.
Thanks a lot sysrpl.
This solution based on ActiveX and Internet Explorer. Required to write too much additional code for each JavaScript function/fearture you going to use.
I strongly suggest take a look on SpiderMonkey (Firefox) javascript wrapper. It's ready for RTTI.
http://code.google.com/p/delphi-javascript/
Required only 1 DLL. Compatible with XE2/XE4/XE5. Ready for x86 and x64 systems.
You can use one of JavaScript interpreters that are available on the market. First of all it's Windows Scripting Engine itself, that offers JScript (delphi wrapper would be needed for comfortable work). Next, it's FastScript by FastReports. There are more available, but I don't remember the names at the moment.
The problem, though, is that the language itself is not enough. What you seem to want is to use JavaScript code which makes use of HTML DOM and various browser classes. Obviously they are not available unless you have a browser engine itself in your program. I.e. if you embed TWebBrowser or link to Mozilla engine, you get the browser and you can run scripts inside of the browser window.
But if you want to automate Delphi GUI with JavaScript, this is probably not the best idea - browser-located JavaScript code will be useless for this.
A lot of questions have been asked and answered about running server-side javascript on Google App Engine, but all of the answers deal with Java instances in order to make use of Java-based JS interpreters like Rhino, Rhino for Webapps, etc.
Is there any way to execute server-side javascript code on a Python GAE instance? I'm thinking something exactly along the lines of pyv8, but with support for App Engine (which I guess would mean a pure python implementation of the interpreter).
The only solution I can come up with at the moment is to use some sort of gross hack to run a Java and Python GAE instance side-by-side (via different versions) so they can both talk to the same datastore, let the Java instance host the JS code, and use an API to talk back'n'forth. Not very appealing.
No need to get into all the "this is unnecessary, you shouldn't be doing this" discussion -- I know this isn't ideal and I'm simply curious if it can be done.
As far as I can find: No
I've done a bit of searching, but it seems that nobody has tried to implement a pure Python Javascript engine, and I can't blame them: it would be a huge amount of work for very few use cases (unfortunately, yours is one of those). A couple of projects—Grailbrowser and Pybrowser—have Python code to render HTML, so might one day aim to run javascript, but it's not even started, and neither of them look in active development.
The most likely way it would ever happen is if Google were to offer the Parrot VM (which can run various dynamic languages) on Appengine. That's a cool idea, but I'm not holding my breath.
What might work is to run Jython (and Rhino) in a Java instance. Of course, then you'd have to get to any App services through the Java API, not the Python one, which would be ugly.
Actually, it can indeed be done, using either AppEngineJs or ESXX:
http://www.appenginejs.org/
http://esxx.blogspot.com/2009/06/esxx-on-google-app-engine.html
I am currently trying to solvevthe same problem with PyJON
http://code.google.com/p/pyjon/
Seems to be a pure Python JavaScrit parser an interpreter.
I would like to create a database backed interactive AJAX webapp which has a custom (specific kind of events, editing) calendaring system. This would involve quite a lot of JavaScript and AJAX, and I thought about Google Web Toolkit for the interface and Ruby on Rails for server side.
Is Google Web Toolkit reliable and good? What hidden risks might be if I choose Google Web Toolkit? Can one easily combine it with Ruby on Rails on server side? Or should I try to use directly a JavaScript library like jQuery?
I have no experience in web development except some HTML, but I am an experienced programmer (c++, java, c#), and I would like to use only free tools for this project.
RoR is actually one of the things the GWT is made to work well with, as long as you're using REST properly. It's in the Google Web Toolkit Applications book, and you can see a demo from the book using this kind of idea here. That's not to say that you won't have any problems, but I think the support is definitely out there for it.
There's a neat project for making RoR/GWT easy that you can find here (MIT license). I haven't had a chance to try it out yet, but it looks like a good amount of thought has been put into it. One catch is that it looks like it hasn't been fully tested with 2.1 Rails yet, just 2.0, so you may run into a few (probably minor and fixable) errors.
If you are looking to integrate GWT with non-Java backends such as ROR, PHP etc., you should bear in mind that GWT 1.5 now supports JavaScript Overlay types. This feature lets you write classes that can be mapped over the top of native JavaScript objects to easily provide accessor methods for properties of those objects and other extended functionality.
See this link for more details:
JavaScript Overlay Types
So you could return JSON encoded data from your backend via AJAX calls, parse it into a JavaScript Object and then access the data through your GWT Java code using the overlay classes you've created. Or when you render your page you can render static config data as JavaScript Objects and read it in via this mechanism, rather than having to do an AJAX call to grab the data.
If you know JAVA, and have somewhere you can host it (like a tomcat or glassfish container) I would recommend that much more than using Ruby for the back end. The main reason is that then you can share all of your objects, and use the built in RPC mechanism. I've done this for quite a lot of our projects and it's a huge timesaver, not to mention that the code is less error prone, because you don't convert your java objects to anything and then back again.
I have linked my GWT with Rails before, using the to_json function in Rails and then reading the JSON in GWT. It's all supported, but it is far more annoying than just doing the back end in JAVA.
Of course if you have cheap hosting, then Java containers are pretty much out of the question, in which case I would think Rails would be the next best thing.
GWT is very high quality with a great community. However you do need to know CSS if you want to adjust the look of things (you will) - CSS can do a lot of the layout, just like regular web if you want it to. Libraries like GWT-ext or ExtGWT can help a bit as they have stunning "out of the box" looks but for a price (extra size to your app).
You can code everything in Java using GWT, and you can integrate existing 3rd party javascript libraries with it. It's very good. I've never used RoR much though, so can't say anything about that.
If you're experienced in Java but not in Javascript/CSS, then GWT is going to be a lifesaver (unless you want to learn them, of course). CSS has so many little fiddly details. It is not uncommon to spend half a day fixing a 2 pixel misalignment that only occurs in IE6.
I am not sure about how easy it would be to use ROR for the back end... It is possible, I am sure, since GWT ajax communication is just servlets. But they provide some really nice functionality for passing Java objects back and forth which you won't be able to utilize if your server isn't also using Java.
I wrote about some of the disadvantages of GWT recently. Mainly, the disadvantages are: long deployment cycle for changes to some parts of the application and a rather steep learning curve. As a seasoned Java programmer, the second should be less of a problem and if you use a seperate backend, the first is also mitigated (as a complete redeploy is primarily required when you change the 'server' part of the application).
GWT is a wonderful framework with lots of potential. Keep in mind that it's still quite new, though. There are some unresolved bugs that can really annoy you, and they usually require ugly workarounds to get past. The community is great but you'll probably end up with a few problems sooner or later that Google can't answer yet.
But hey, I say go for it. The potential for GWT is awesome, and I bet it's future will be bright.
You should definitely use GWT for a new project (it's pretty easy to use in an old project too).
I my experience it's very fast to learn and use. The compiled javascript code is much better than anything you could ever write by hand and it works fast too.
Another benefit is the ability to debug you're code (which is hell with javascript alone)
This blog has inputs from many experienced users of GWT and have some great discussion points. I personally have huge experience with varied UI Frameworks. I will add my two cents. Lets look at fundamental advantages and disadvantages of GWT
Fundamental Advantage
GWT takes the web layer programming to JAVA. So, the obvious advantages of Java start getting into play. It will provide Object Oriented programming. It will also provide great debugging and compile time checks. Since it generates HTML and Javascript, it will also have ability to hide some complexity within its generator.
Fundamental Disadvantage
The disadvantage starts from the same statement. GWT takes the web layer programming to JAVA. If you know JAVA, probably you will never look out for an alternative language to write your business logic. It's self sufficient and great. But when it comes to writing configurations for a JAVA application. We use property files, database, XML etc. We never store configurations in a JAVA class file. Think hard, why is that?
This is because configuration is a static data. It often require hierarchy. It is supposed to be readable. It never requires compilation. It doesn't require knowledge of JAVA programming language. In short, it is a different ball game. Now the question is, how it relates to our discussion?
Now, lets think about a web page. Do you think when we write a web page we write a business logic? Absolutely not. Web page is just a configuration. It is a configuration of hierarchical containers and fields. We need to write business logic for the data that will be captured from and displayed on the web page and not to create the web page itself.
Previous paragraph makes a very very strong statement. This will explain why HTML and XML based web pages are still the most popular ones. XML is the best in business to write configurations. A framework must allow a clear separation of web page from business logic (the goal of MVC framework). By doing this a web designer will be able to apply his skills of visualization and artistry to create brilliant looking web pages just by configuring XMLs and without being bothered about the intricacies of a programming language. Developers will be able to use their best in business JAVA for writing business logic.
Finally, lets talk about the repercussions in direct terms. GWT breaks this principal so it is bound to fail. The cost for developing GWT application will be very high because you will need multiskill programmers to write web pages. The required look and feel will be very hard to achieve. The turn around time of modifying the web page will be very high because of unnecessary compilation. And lastly, since you are writing web pages in JAVA it is very easy to corrupt it with business logic. Unknowingly you will introduce complexities that must be avoided.
You could also consider Grails ("Groovy on Rails") which gives you the benefits of a Rails framework and the use of the Java VM.
Our team recently asked the same question, and we chose to go with GWT, especially since the designer plugin made working with GWT more accessible to non-java experts on the team. Whoever makes this choice, just beware you DON'T use the GWT Designer plugin !! It has not been updated (in at least a year, apparently) to create a GWT application that is compatible with IE8.
Our team had almost completed our application layouts, which were working perfectly in Chrome, FF and Safari. Then they blew up in IE. IE 7 would load partial pages (but not composite includes), and IE8 was not even able to load up the application. It just hung.
The designer plugin has buttons that allow the user to add CellTable widgets that are not IE compatible (CellTable, DeckPanel, Horizontal Panel, Vertical Panel, among others). These will cause intense pain when the layouts have to be re-done in java without assistance from the designer.
Experienced GWT users love it, but the designer plugin will kill you.