Hi Julián, This is exciting! In Sandstorm we have a lot of use cases for speaking Cap'n Proto all the way from the browser, but we have not been able to find time to work on JS bindings. We would also like to ditch the V8-specific implementation we use server-side in favor of a pure-JS implementation.
Some thoughts: - You list WebSocket as a stretch goal, but how do you imagine implementing RPC without WebSocket? It seems to me that this (or a WebSocket emulation layer like sock.js) is a necessity given the symmetric nature of Cap'n Proto RPC. - For Sandstorm, being able to use postMessage() as a transport would be extremely useful. Of course, combining WebSocket, postMessage, WebRTC, and server<->server TCP, all with 3-party handoff (level 3), would be the holy grail... but tricky. :) - Hmm, what are the "speed" reasons to use pure ES5? I'm not familiar with this. - Have you considered using TypeScript or Flow? Cap'n Proto follows a strongly-typed philosophy, and although Sandstorm does not use strongly-typed JS today, everyone on the team wants to move towards it in the future. -Kenton On Fri, Sep 30, 2016 at 5:08 PM, Julián Díaz <[email protected]> wrote: > For better or worse my curiosity has led me to try reviving the JavaScript > implementation of Cap'n Proto; at least all the way to level 1 RPC in > native JavaScript. > > Looking at the current two implementations they don't really feel viable > to hack on - one is using AMD for the browser (we've moved on!) and the > other is clearly a mess as-is. > > After scratching the surface a good bit, my initial goals for the library > are: > > - Full level-1 RPC support > - Extensive unit test coverage > - Full browser and nodejs compatibility > - Pure ES5 implementation (for speed) > - Low-to-zero library dependencies (lodash might become a must-have) > - Loading schema files directly > > Stretch goals: > > - WebSocket transport support > - Precompiled schema files > - Web worker support > - Level 2+ using WebRTC (can it be done!?) > - First-class support for bluebird promises > > Would love some feedback from this list to hear if there's appetite for > this, and any features that would make this super useful. I will initially > aim to provide a similar API as the reference C++ implementation but I may > take extreme measures to cater more to the target language and typical > audience. I personally tend to prefer stateless, immutable APIs and will > try to support that here as well. > > - Julián > > -- > You received this message because you are subscribed to the Google Groups > "Cap'n Proto" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > Visit this group at https://groups.google.com/group/capnproto. > -- You received this message because you are subscribed to the Google Groups "Cap'n Proto" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. Visit this group at https://groups.google.com/group/capnproto.
