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.
--
Mailing list: https://launchpad.net/~leaningtech-dev
Post to : [email protected]
Unsubscribe : https://launchpad.net/~leaningtech-dev
More help : https://help.launchpad.net/ListHelp
