It is stalled, I'm afraid. Not quite in a condition where someone else could pick it up, either. This is mostly due to lack of time with work obligations, though that's on track to change soon.
Truthfully, I may need to nuke-and-pave the current repository and start over with ES5 JavaScript. Translating the C++ code more or less verbatim has proven extraordinarily difficult for three reasons: pointer arithmetic (I managed to create nice helpers to deal with this), C++11's robust templating and type system which is used *heavily* in the capnp source (TypeScript cannot come close), and pass-by-reference function arguments which are *mutated* by the method itself (JavaScript cannot do this). I totally understand now why the other two JS libs have been basically abandoned. I'll use ES5 directly for the second pass rather than ES6/2016/etc since I'll have much tighter control over the performance characteristics that way. I will also take more of a top-down approach and loosely follow the C++ API, only taking bits of inspiration from the original source when appropriate. This is easier now that I have a deeper understanding of the internals. Switching the library to ES5 isn't a death sentence for TypeScript support. I can manually generate type definitions for the library and even potentially have the code generator output full typescript or type definition files as well. In any case, this project hasn't been forgotten! On Friday, April 7, 2017 at 10:24:42 PM UTC-4, Wink Saville wrote: > > Julian, What's the status of this? > > On Tuesday, October 4, 2016 at 8:13:51 AM UTC-7, Julián Díaz wrote: >> >> Generated TypeScript it'll be, then! It'll be pretty trivial to >> subsequently invoke the TypeScript compiler on the TypeScript generated >> code to get "free" ES5 code for everyone else. >> >> I'm really digging how much of a great fit TypeScript's type system is >> for this stuff (so far, at least). Will report back once I have something >> that resembles a code generator. >> >> On Sunday, October 2, 2016 at 6:15:06 PM UTC-4, Kenton Varda wrote: >>> >>> For Javascript, I actually don't think runtime schema loading should be >>> a goal. These days Javascript is essentially a compiled language anyway, >>> with all the transpiling and minifying. And to load schemas at runtime in a >>> browser, you'd presumably need to rewrite the parser in pure-Javascript. >>> I'd like to avoid having multiple schema parser implementations as they'd >>> be likely to have subtle incompatibilities that would be a pain for >>> developers. >>> >>> So, yes, capnp -> TypeScript compile-time codegen sounds like a pretty >>> good plan. Then we can get auto-complete in our IDEs and all that cool >>> stuff. :) >>> >>> -Kenton >>> >>> On Sun, Oct 2, 2016 at 10:31 AM, <[email protected]> >>> wrote: >>> >>>> After playing around a little and realizing how limited ES5 really is, >>>> I'm open to writing this thing in 100% TypeScript. There's some caveats, >>>> though - if the schema file is loaded dynamically it'll be hard >>>> (impossible?) to add type safety without runtime type checks, and I can >>>> see >>>> that getting expensive. TypeScript almost gets in the way in this case. >>>> However, a schema compiler can be set up to emit either typescript or >>>> vanilla ES5 code; *that* could work quite well! ArrayBuffers will >>>> contain the raw data and property access/method calls will just reference >>>> indices in the array - the only *super* annoying thing about it is >>>> there's no native support for 64-bit words in JavaScript so everything has >>>> to be broken up into hi/lo 32-bit words in a Uint32Array (yuck!). >>>> >>>> There are concerns about TypeScript being generally slower if you lean >>>> heavily on the ES6 features (https://kpdecker.github.io/six-speed/), >>>> but with proper profiling it shouldn't be hard to identify hotspots and >>>> turn them into tightly optimized code that won't be modified much by the >>>> transpiler. The speed problems come in when you heavily depend on things >>>> like arrow functions and the transpiler ends up adding extra assignments >>>> and variables you didn't expect. For what it's worth, I expect most >>>> performance concerns won't have anything to do with using ES6. >>>> >>>> I agree that the transport layer needs to be pluggable and that's the >>>> design I'm going to go for right from the start. Realistically I'm going >>>> to >>>> have a hard time designing the whole thing without a sample app to >>>> reference so *some *form of transport needs to be supported "out of >>>> the box". WebSockets feels like an easy initial target for this. >>>> Supporting >>>> window.postMessage should also be easy, and since you can pass >>>> ArrayBuffers >>>> with zero-copy (I think??) it'll be crazy fast! >>>> >>>> Speaking of sample app; I plan on writing a TodoMVC type thing in >>>> separate repos as a reference implementation (a node server and a browser >>>> client w/ React). Any thoughts on this? Should I instead try to go for >>>> something that better showcases the power of capability-based access >>>> control? A todo list where you can securely share edit/view access with >>>> others could be a fun demo. I want to keep the UI complexity low and >>>> really >>>> focus on the RPC stuff, of course. >>>> >>>> Could also use tips on which order to implement things since this is a >>>> bit of a *daunting* spec to implement. I'm currently having fun with >>>> the unpacking algorithm. :) >>>> >>>> On Saturday, October 1, 2016 at 7:56:02 PM UTC-4, Nathan Hourt wrote: >>>>> >>>>> 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. >>>> >>> >>> -- 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.
