Re: Sync API for workers

On 12 oct. 2013, at 08:14, piranna@gmail.com<mailto:piranna@gmail.com> wrote:

It's a safe assumption, but I think it's better to be asynchronous also on workers, not only for efficience, but also for having only one programming model so you can easily interchange your code between workers and main thread and also maybe Node.js.

Having Synchronous code able to run in workers allows to interchange code between workers and Wakanda which natively supports sessionStorage, Web Workers (Async), XHR (Sync and Async), Blob, FileSystem (Sync and Async) with upcoming support of the Web Sockets API (Async) and others

It could also allow, with potential polyfills, to interchange code between workers  and Rhino, Helma / RingoJS, TeaJS (aka v8cgi), SilkJS, GPSee, ArangoDB

Look at IndexedDB API, since asynchronous one was enought dfor everybody, synchronous one was not implemented by the browsers and now it has became deprecated... :-)

Well regarding my position I would not smile ;-)
I was considering a server-side implementation of indexedDB. There is currently the indexeddb-js project for Node using sqlite-3
We may consider some IndexedDB implementation with Sync API support for other SSJS platforms (Sync and Async are both interesting on Wakanda)
It could support remote document stores like MongoDB, CouchDB instead of only a local sqlite, and might be agnostic via adapters and settings
(If one is interested to work on that with me, contact me)

As a disclaimer, for your information, I'm currently involved in the Wakanda platform which provides Synchronous and Asynchronous JavaScript APIs on the server as well an Ajax Framework. While Web Workers are already surrported, in some of our next releases, all server-side JavaScript contexts will be considered as workers, and should be considered by clients as remote workers (the server let debug those contexts via Web Inspector).

The server-side context is of course a bit different, I explained on quora some of the reason of using JS on the server other than coding in an EventLoop:
http://www.quora.com/Node-js/Why-should-I-write-Javascript-on-the-server-side/

and as you mentioned it, one of the reasons was to be able to share code between client and server (even more useful in offline mode)

I did present this approach, as well as the "Remote Workers" one,  this last week-end during The Geek Gathering conference:
http://www.slideshare.net/alexandre_morgaut/end-toend-html5-apis-the-geek-gathering-2013

It was a refactored version of discussion done last year during TPAC to present the "Client and Server JavaScript APIs Community Group"
http://www.w3.org/community/jseverywhere/


I like the JavaScript EventLoop strength for async coding, as I appreciates the upcoming promises, but still, as some people in this list I think that synchronous code is more user friendly. At least, even using Promises, sync code version is way lighter with less boilerplate, and let the developer focus on the intended main behavior.

Another good point for sync API is that it's way easier to debug when stepping. Step into will not (and should not) step into the callback provided as a parameter. To be sure to step in the callback code, you often need to add additional breakpoints, and you will sometime need to make it conditional to stop only in a specific context.

Alexandre.

[cid:8c5758.png@00b934d0.40bd08d5]
Alexandre Morgaut
Wakanda Community Manager
Email : Alexandre.Morgaut@4d.com<mailto:Alexandre.Morgaut@4d.com>
Web :   www.4D.com<http://www.4D.com>

4D SAS
60, rue d'Alsace
92110 Clichy - France
Standard :      +33 1 40 87 92 00


[cid:79861f.png@00cb6187.46a6beae]<http://www.4d.com/fr/company/events/summiteu2013.html>