End-to-End API (TPAC breakout session) -- 31 Oct 2012

<scribe> scribe: Francois Daoust

<alexandremorgaut> slides: http://www.slideshare.net/alexandre_morgaut/endtoend-w3c-apis-tpac-2012

<scribe> scribenick: tidoust

<alexandremorgaut> slides again: http://www.slideshare.net/alexandre_morgaut/endtoend-w3c-apis-tpac-2012

Alexandre: Presenting myself, working for 4D recent new member of W3C. Business Web applications. Very concerned about interoperability and not duplicating code.

… Willing to make things as easy as possible.

… Two things interesting: REST and code on demand. If we are to choose a single language for servers and clients, the best solution seems to be JavaScript, because it's there.

… That's the reason of the success of backend solutions such as Node.js

… On the server, we only have EcmaScript, not the browser context. No XHR, … so most servers don't implement W3C APIs right now.

… Not very new. JScript, Rhino, … More than 60 server-side implementations of JavaScript. Some of them combine to define module APIs. CommonJS.

… They tried to make low-level APIs, but difficult as many competing proposals

[Slides: http://www.slideshare.net/alexandre_morgaut/endtoend-w3c-apis-tpac-2012 ]

Alexandre: We really wanted to share code between server and client, in particular for security reasons to have the same code. If the application runs offline, it needs to remain consistent with the application if it is run online. There needs to be some proxy.

… Different technologies to do that: Indexed DB, Web Storage, ...

… Note I'm not only talking about HTTP servers, there are many databases that use JavaScript.

Daniel: Are you concerned about JavaScript or about APIs that don't really care about the underlying language?

Alexandre: addressing the JavaScript use case because it's the pertinent one on the Web.

Daniel: Makes sense to use it as an example. For instance, the DOM API doesn't care about the underlying language.

Alexandre: exactly.

… In Node.js, own proprietary APIs but you can install modules.

Daniel: When you talk about the File system, can you use the same abstraction as in DAP?

Alexandre: coming more into details into specific APIs, but yes, we're looking about common abstractions.

… We're looking about cloud here as well.

… Mentioning a few interesting APIs: XMLHttpRequest, Web Cryptography, File System, Storage Quota, System Information, Web Workers, Web Sockets, Web Storage, Web CL (not yet W3C, but still), WebSQL.

… There was a mention on WebSQL spec saying it was stopped because there was only one implementation.

… On the server, we wouldn't have this limitation.

… Having WebSQL API is really meaningful on the server.

Daniel: So you want JSDBC.

Kris: In Web Apps, we put the WebSQL spec to rest in profit of IndexedDB. You're suggesting that it should be reopened. IndexedDB is making good progress.

Daniel: IndexedDB is indeed perfect to access data stores.

… Can we force all backend developers to use Indexed DB? I'm not sure. Maybe WebSQL should come back.

timbl: General question is very interesting. rdflib.js is useful on both sides. Testing through the command-line as well. Running Node.js sometimes on the server or as command-line is useful.

Alexandre: Something great in current W3C APIs is that lots of them implement both synchronous and asynchronous APIs [citing examples]

… When we didn't have workers, it was hard to catch why. With workers, that makes sense.

… Node.js is asynchronous, but most other server-side systems are synchronous, so supporting both would be good.

tidoust: If asynchronous is not supported server-side, that means you can no longer share code between server and client in some cases.

Alexandre: Indeed. It's not always the case. Should we impose developers to write asynchronous code? Good in some cases, not always.
... IndexedDB already gives the example of synchronous API within a worker.

… WebCL goes beyond saying that asynchronous is not mandatory in Web workers and server-side.

… That's a good start to mention these use cases, and would benefit many on-going APIs to think and mention this.

… Good practice for me.

… Then, another aspect that is important for me. We talked about workers similar to server-side environment. Shared workers are similar to what Node.js is doing: one context and many requests coming to that context.

… For dedicated workers, it's different, one context for each request.

… One thing we've implemented to start with is to implement workers.

… I would like to propose that you think about server-side environment as in workers.

… In terms of debugging, it means regular debuggers such as Web Inspector are starting to work with remote contexts, and may now able to debug workers.

… When they go to remote debugging, it's usually for mobiles and thus they provide the same user interface.

… For workers, it opens up a new window per worker, which is not very convenient, but at least they can be used to debug code running in faceless environnements.

… In the future, client-side debuggers should be able to debug faceless JavaScript contexts remotely, meaning server-side JavaScript.

… [going through examples] SidJS has something. Few modules in Node.js. In Wakanda, we try to implement them natively.

… [scribe missed point about Web Storage and User Storage]

Daniel: Back to points on REST and server-side being synchronous. Synchronous RPC is usually REST model.

… For Web access, it's a different model. Often the API is different, because the access model is different.

… How can the APIs account for the difference between existing models?

… How would you handle that issue?

Alexandre: Initially, we were asynchronous, since running without workers. Now, it tends to be the opposite.

… It helps you to share some code if you have server-side implementations which are synchronous.

… Web workers would allow to work asynchronously, so that shouldn't be a show-stopper.

… You can load a process (shared worker), and many requests could share through this process to access a DB, Web Sockets.

… [example of Web sockets and scalability]

… In Node.js, each request will be executed serially as it is single-threaded. A mix may be needed for heavier applications.

Daniel: You could have a case where the same piece of code could access things synchronously or asynchronously depending on the environment. Would it need to be specified? Would I need to use some API that would handle synchronous calls?

Alexandre: synchronous calls

Daniel: So you would need two different classes of APIs.
... If you're going through a sequence "Log in", "review", "order". They are series but each one is asynchronous.

… How would that work?

Alexandre: Easier to use the synchronous API.

… Something I'd like to see with that initiative to see how server-side could be taken into consideration in the development of APIs

… and maybe a document of best practices.

Daniel: Do you have a target group in mind?

Alexandre: WebApps, DAP, SysApp...

Daniel: The DOM of course.

Alexandre: I created a community group.

tidoust: Synchronous vs. Asynchronous, a bit of a pain to have two different APIs. Couldn't we stick to the asynchronous version that can do both?

Alexandre: When the code is generated, it's not an issue.

… It's not that bad to know that you're working with a different API.

Daniel: We see the asynchronous in Web pages, for ads for instance.

… Sometimes, you may want things to be synchronous.

Kris: [missed example about IndexedDB synchronous/asynchronous]

Alexandre: Example of a module we have. Synchronous API hiding the asynchronous API, meaning the developer can concentrate on business code. When it comes to the end user developer, it's better.

Daniel: just looking at IndexedDB spec, there's a section mentioning synchronous calls but at risk.

Alexandre: Right, because there are lots of push in the Node.js community saying that asynchronous coding is better, but at the same time there are others questioning whether that's really the case.

Daniel: There's really a place for synchronous APIs in the world.

Alexandre: In many use cases, if you go the enterprise using business Web apps they don't use that many applications in parallel.

… If you have too much code, it's very good to Web workers and to have more readable code.

… Our speciality at 4D is business apps.

s/[missed example about IndexedDB synchronous/asynchronous]/[missed example about IndexedDB synchronous/asynchronous] The UI may just hang/

Dan: You have to take into account legacy if you talk about business apps. [scribe missed point].

… If you integrate with legacy enterprise applications, asynchronous might be used without a way to move away from that up until all the system is replaced.

Daniel: What are your next steps and actions?

Alexandre: Find people interested in that initiative, joining the community group and maybe reach out to working groups.

… Already 10 participants in the Community Group.

… We really need people for WebApps, DAP, SysApps. People contributing to SidJS are there. Other are welcome to join.

- DRAFT -

End-to-End API (TPAC breakout session)

31 Oct 2012

Attendees

Contents

Summary of Action Items

Scribe.perl diagnostic output