From webassembly.org:
WebAssembly (abbreviated Wasm) is a binary instruction format for a stack-based virtual machine.
In the context of Wasm/WASI, what is
a WebAssembly runtime?
a WebAssembly interpreter?
a WebAssembly engine?
and in the above context:
the host environment?
I suppose the practical meaning of these terms can differ when used in a web browser context, but I think focus should be on the native usage of Wasm code.
I must admit, I preferred their previous summary of the technology:
WebAssembly or wasm is a new portable, size- and load-time-efficient format suitable for compilation to the web
To be specific WebAssembly is an instruction set, it looks quite like regular assembly language, with a low-level 'feel' to it. The language supports numeric types only, no strings, arrays etc ...
The WebAssembly specification also defines the virtual machine that it runs on.
To answer your questions:
what is a WebAssembly runtime?
It is a machine, or virtual machine that can execute the WebAssembly instruction set, as described by the specification. You have one in your browser!
what is a WebAssembly interpreter?
Interpreters and compilers are two different approaches to executing a language - as described here:
How does an interpreter/compiler work
what is a WebAssembly engine?
Pretty much the same as a runtime.
the host environment?
WebAssembly runtimes typically live within a host - this is because WebAssembly itself cannot perform any I/O. In order to do something useful, it works with the host environment to achieve this.
Related
I would like to access a COM interface from a WebAssembly module. If possible, this will be my first WebAssembly module. Can it be done? What challenges and/or restrictions might I face when accessing a COM interface from WebAssembly?
WebAssembly is more or less like a virtual machine, one can't communicate directly with any other parts of the system if the needed interfaces aren't implemented or provided for the virtual machine. WebAssembly won't provide such thing for you, thus, you (or some project probably doesn't exist yet) have to do more work to make such thing happen.
Would the JVM (and probably also the CLI) be considered a virtual machine (the equivalent of the x86 in a "normal" program stack) or a virtual OS (the equivalent of Windows)?
Strictly speaking, it is a virtual machine, ie: it executes a special low-level language (similar to x86 ASM. CLI uses MSIL, JVM uses "byte codes") and translates them into the target machine's op-codes (x86, x86_64, ARM .. etc.) for execution on the host CPU.
It also manages marshaling (ie: correct handling and passing through of variables to native memory stack/heap) to allow function calls from inside the managed world to the outside OS on which the VM runs.
Practically though, neither the JVM nor the CLI alone are very helpful except for automated garbage collection and CPU-architecture-independence, but they are complemented by a large base library (the Java classes, or the .NET BCL) which allows you to do many platform-y things without having to call platform specific APIs and use marshaling manually for everything.
That's why there is a different Java Runtime Environment for each OS. Each one's JVM translates to a specific CPU arch, and uses different platform specific-APIs to accomplish what the unified base library exposes to you as a friendly API inside the managed world.
Hope that helps you.
The jvm is considered a real computer, only not realized in hardware. The machine has it's own storage capacity, it's own memory model, it's own specific behaviour of it's central processing unit and it's own internal machine code. This machine is extendable with new possibilities and modules that are represented with classes, API's, etc...
It has it's own stack based architecture, like most virtual machines.
I saw that the Clang 3.0 port includes Objective-C as a development language, and furthermore, I also found this port "libobjc2-1.6" (Replacement Objective-C runtime supporting Obj-C 2 features) and "ofc-0.8.1_5" (The Objective-C Foundation Classes library).
Let's say we are considering to use Objective-C on FreeBSD to develop a web-based application (vs. using Java and running it on Tomcat/Glassfish), how do we approach it?
Does Objective-C development actually work on FreeBSD (9.0)?
What are the things (frameworks/library) to download and install?
What IDE?
As I mentioned that let's say we intend to develop a web application, what are the library?/libraries (We also saw that there is "GNUstepWeb" - successor to WebObjects - is this the web library we should consider? Is this the ONLY ONE - what about other alternatives? Further, can GNUstep/GNUstepWeb compile under Clang 3.0 or make use of those Objective-C ports ("libobjc2-1.6" and "ofc-0.8.1_5") mentioned above? Are those ports relavant?
Has anyone successfully done a web application project development on FreeBSD using Objective-C (and deployed on FreeBSD)?
Note: Web-based applications means it takes in HTTP (RESTful) calls and talks to a database (for traditional and/or NoSQL databases).
There is http://cocotron.org, a port (more like re-write) of Apple's runtime for Objective-C.
I still could advice against using ObjC for web stack. I did that previously, and I must say that it involves a big chunk of pretty common code that you will need to implement for basic HTTP server functionality.
Also, Cocotron is not really that fast (as a runtime). It's ok for desktop applications, but web world is much more restrictive.
I am writing a library supporting this using FastCGI to interface the server called CGIKit (https://github.com/xcvista/CGIKit) and it works on GNUstep instead of Cocoatron.
you may look at sope and sogo http://sope.opengroupware.org/en/build/thirdparty.html
Someone seems having success building Objective-C program for FreeBSD 9.x
You don't need to worry about the IDE if you don't mind using Apple. It would be possible to write on Mac, and run on FreeBSD. (personally I think this is the best of both world) IMO, if there's a server OS with Objective-C ready, FreeBSD will be first one.
More serious problem is libraries and frameworks. We don't have much options in Objective-C for web server development even on OSX. But we can wrap existing C/C++ libraries, (just as like many great node.js, Python, Ruby libraries do) and I think we may can get bunch of options with small efforts.
Some people worry about security. And I always wonder how many foundational programs on the network are written in C/C++ and other languages.
In his blog post “Using Objective-C on the server” Graham Lee describes how to set up a minimal GNUStep-WebApp. Obviously, the build instruction for GNUstep-make would differ, but other than that this seems like a nice starting point.
He wrote several other posts (jQuery, AJAX) further exploring GSW.
Is Mono appropriate for developing server applications, or only desktop applications? I'd like to develop server applications in C# for Linux. I want to write a First Person Shooter (FPS) game in C#/XNA, and I've a Linux dedicated server. But this question is generally for all types of server applications...
Mono handles ASP.NET (including ASP.NET MVC) quite well. Most other server implementations work very well, as well. It does depend, slightly, on what exactly you are trying to serve, and how you are going to use it.
Mono also supports WCF directly in the core, which allows most non-web service applications to be written very effectively.
Edit:
Given your edit, and your desire to handle the server side of a multi-player FPS game, Mono should work fine. You will likely want to avoid using the high level interfaces like WCF and ASP.NET, and go straight to the System.Net namespace (depends a bit on how many players you'll be synchronizing, but if it's large, you'll want speed here over ease). Mono supports this quite well.
That being said, Mono's support of the System.Net namespace is very good, and quite mature, so you should have no problems using it for the server side of a multiplayer FPS game.
I don't see why not. I believe FogBugz uses Mono to deploy to apache servers.
Here is a conversation about running the FogBugz application on mono as an example of having a server app running on it.
It looks like your needs cover a broad range of different applications.
I think the overall answer would be yes, Mono is appropriate for developer server applications.
As others have pointed out, Mono has ASP.NET support as well as WCF built-in.
You also have the ability of working directly down to the Socket level if you need to squeeze every last bit of performance out of your server application (although you'll have to figure out how to persist state if the need is there).
I'd definitely be interested in seeing the performance difference of something like that between the two platforms (I wouldn't expect much difference...it's possible that Mono might even get slightly better performance because of the rest of the *NIX stack).
OS : Linux.
I'm trying to find possible ways to implement web interface for my embedded system.
Currently there is a shell (text based) and a small set of commands are implemented to query the device.
I'm new to web development, my questions are:
What web server must I use? (I got apache up on my development setup and tried using CGI to fetch some pages, but seems like this not the right choice for embedded systems)
Assuming I'm using CGI, what strategy can be used for passing data between CGI and the Main App?
I intended to create a thread in the MainApp to handle the query from CGI script. This thread would call interfaces in the MainApp, retrive the data and pass it to CGI.
We use Lighttpd on our embedded systems, it's small and very easy to integrate. There are also specialized webservers with features especially geared to embedding, like AppWeb, which in my opinion is also a very nice product.
For the communication between the main application and the CGI's you can use sockets, or System V message queues if those are available on your embedded platform. The advantage of SYSV message queues is that they're very easy to use and manage, and messages in the queues survive restarts of the applications, but they also have some quirks (like you can't select() on them).
As web server another choice is thttpd. I use it successfully in an industrial product.
For the communication between CGI and main application sockets is the right choice.
There is no web server you must use, but there are some better choices for embedded than apache. Apache is designed for embedded and is bigger and slower.
I would not recommend CGI. It is slow to run and slow to develop. I can speak for Appweb for which I'm one of the developers. Appweb has two good web frameworks:
Ejscript which is a server-side Javascript framework for Appweb
ESP which is an MVC C-Language web farmework
ESP is extremely fast and provides easy binding of controllers to URLs. Ejscript is bigger and has a more extensive class library. Both are designed for embedded. Both are much better than CGI and execute 20+ times faster than CGI.
I am working in LuCI, which is a light CGI for embedded device. Actually it is for openwrt which is a open source project of wireless router.
The server is uhttpd , light and powerful.
The CGI script is Lua whose interpreter is no more than 10k, delicate, right? And it is developed by C and can communicate with C, powerful.
So this is my suggest.
We use JUCI with openwrt. It is written in javascript that runs on the client browser and communicates with web server over json rest api. The backend can be implemented in any language but we use reusable components written in C that plug into system bus (ubus). This means that relevant services expose their functionality through ubus which can both be used through cli and through rest api. It's actually pretty nice.