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, <julia...@onefinancialholdings.com> >> 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 capnproto+...@googlegroups.com. >>> 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 capnproto+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/capnproto.
