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.
