As far as the appetite front goes, I've rather wanted a pure javascript implementation of capnp on several occasions now, so I'd be quite happy to see this happen.
I think websockets support is a must, but ideally the library would be sufficiently portable that I would be able to use the library, unmodified, on any particular transport layer I want, with nothing more than a little glue code between interfaces. The library could then provide some built-in adaptors for common transport layers (like Node sockets, websockets, etc) which would allow those transports to be used with no customization, and also documents how to write adaptors so it's easy to see how to use other transports instead (exactly like what we see with the C++ implementation with AsyncIoStream: I can use any transport I want simply by implementing the interface). On Friday, September 30, 2016 at 7:08:01 PM UTC-5, Julián Díaz 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.
