Capibilities that needs clarification

Hi Edward,
thanks a lot for the interesting questions, I'll try to answer each one.

* File IO
Currently files are not supported. There is work in progress to support stdout/stderr for debugging. In perspective I don't think that emulating files on top of http requests is a good idea, since it would not be possible to provide complete and sound support for what it is expected by a filesystem. On the other hand the Filesystem API looks definitely interesting and when the API gets more stable we will consider using it as a backend for standard file API. Of course, since duetto does not limit what you can do on the browser, it is already possible to use XMLHttpRequest to load data. By also declaring signatures for the file system api it could be possible to use it as well.

* Sockets
Sockets are a POSIX API and a web browser is not a POSIX enviroment. Although simple cases could be definitely handled, it would be not possible to implement complete support for the socket API and we believe that is better not to implement something than to implement it poorly. But again, you can use WebSockets directly. Generally speaking our policy is to work hard to provide low level access to every browser capability, on top of that other developers may write higher level libraries to ease writing new code or porting existing one. So it possible that the communty will write a socket-like wrapper for network programming inside the browser, but we won't be doing it in the short-term.

* Multi-threading
Yes, multithreading is not really supported in JavaScript, beside WebWorkers. As usual WebWorker should be usable, but off the top my head I cannot say if their signatures are already exported in our headers. About <mutex> and <atomic>, it's not possible to support them properly, but they are also useless and kind of harmless (in a single threaded environment) so I'll take a look at supporting them as counters (for mutexes) and regular integers (for atomic) to make porting easier. About <thread> there is almost nothing to be done. Multi-threaded programs will need to be refactored in an event based form to run on the browser and pretending to support threading will actually do more harm than good in my opinion. The right thing might be to actually remove the header so that the compiler will let you know every time a threading construct is being used.

* GLES 2.0
We are actually working on a GLES wrapper (called WebGLES) to make porting easier. The wrapper will still expose the underlying WebGL context because a few operations are much more efficient if done using WebGL. For example textures can be loaded directly from image elements, in which case the browser will do the decompression for you. About EGL I believe that it is mostly used to allocate windows and GLES contexes, but please report other use cases. I think that part will need to be ported. We will provide an initialization call in our GLES wrapper that will be used to choose the canvas that will host the rendering and this should be pretty much the equivalent of allocating a window.

* Sound API
Although the signatures are not already in our headers, it will be possible to use the Web Audio API offered by (most recent) browsers. We don't plan to wrap this inside OpenAL since (as stated before) we prefer offering low level access and let developers use it as they want. It is definitely possible to write an OpenAL backend for duetto directly in C++ and then use it in your C++ app.

* Asynchronous transparent RPC
Currently client/server calls are synchronous, but we are experimenting with a type safe async call architecture. Of course lambdas can be already used as event handlers for any kind of JavaScript event, this also means that you can use XMLHttpRequest and lambdas to implement asynchronous calls already, but it would be not type safe and uglier than the integrated solution provided by duetto.

We know that emscripten tries to be helpful in providing support for some frequently used libraries like SDL and OpenAL but AFAIK those are re-implemented in JavaScript (e.g. https://github.com/kripken/emscripten/blob/master/src/library_openal.js).

With duetto we are trying to do something different. We really believe that C++ can be a strong player in the Web programming world and we are focusing on making it _really_ flexible and powerful. What we want is to make it possible to implement an SDL backend for duetto directly in C++, not to re-write a partial implementation of the whole library in JS.

> About <thread> there is almost nothing to be done. Multi-threaded programs will need to be refactored
> in an event based form to run on the browser and pretending to support threading will actually do more
> harm than good in my opinion. The right thing might be to actually remove the header so that the compiler
> will let you know every time a threading construct is being used.

And if I want to spawn a thread in the server-side Duetto code?
Wouldn't removing a header prevent me from doing that?
Wouldn't it be better to have a static assertion failing only when the threading is used in the client-side code?

The client and server side are actually built using a different set of system headers. If an header is only available on the server side (e.g. non C++ threading support like pthread.h) you can wrap it inside an #ifdef __DUETTO_SERVER__/#endif. You can still mix and match client and server code in the same file since errors in the body of server methods will be ignored while compiling client code, since they will not be actually compiled anyway but only parsed.

It also possible to write client and server code in separate cpp files. You can then declare the server methods in a common header file (like you would declare any other externally implemented method). In this way the client code will be able to compile the right stubs for the RPC automatically.

In current git master <mutex> and <atomic> are supported, in the sense that they behave like plain counters and normal integers, which should be ok on the single threaded web platform. An explicit error is not generated if <thread> is included.