leaningtech-dev team mailing list archive

[Alessandro Pignotti <question238531@xxxxxxxxxxxxxxxxxxxxx>]

Question #238531 on Duetto changed:
https://answers.launchpad.net/duetto/+question/238531

    Status: Open => Answered

Alessandro Pignotti proposed the following answer:
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.

-- 
You received this question notification because you are a member of
Leaningtech Team, which is an answer contact for Duetto.