On Tue, 24 Jan 2017, at 18:24, Daniel Munch wrote: > Thanks Jan for clearing things up, I couldn't have answered better > myself! And thanks everybody else for the feedback so far. > > >> That clears it up, One more question if I may. In use would this > >> QueryServer replacement module be an adjacent process to the CouchDB > >> process, or is there some linking fu to make CouchDB and CouchChakra one > >> process? > > > > I haven’t looked to closely, but how I understand it, this is a separate > > process. Just like it with CouchDB today (you have a beam[.smp] process > > and zero or more couchjs processes). > > It currently takes exactly the same approach as couchjs - one beam > process, zero or more couchjs processes, that's why I called it a > drop-in replacement. In theory you could switch out couchjs by > couch-chakra and everything should work like before. > > > While it is absolutely possible to link everything into one process, > > that’s usually not done. > > Actually that's what I tried in the very beginning, writing a NIF to > wrap the ChackraCore API to Erlang functions. While in theory this > would be possible it's however heavily discouraged by the Erlang gods > to write NIFs with non-deterministic timing. So I quickly stepped back > from the NIF idea and instead implemented couch-chakra. > > Also, like Garren said in a mail before, there has been a couple of > attempts to redesign the Query Server Protocol and the process model > for the javascript query server. It looks as if there were different > opinions on this, and it also looks like it could become a lot of > work. Personally I'd love to see a binary communication protocol > between couchdb and the query server and thought that BERT and > BERT-RPC [1] might be a viable option. I'd also love to exploit the > rental threading model of ChakraCore like it is explained in the > article on how Chakra is used in DocumentDB [2]: "In other words, a > runtime only operates on one thread at a time, but its thread affinity > is free to change from time to time." > > Add libuv to the sauce and we might win the next buzzword-bingo > contest with distinction, but that's what this project currently > represents for me: A playground to explore weird ideas and to have > some fun hacking on in my free-time. > > Best, > Daniel
I love this! In particular Daniel's offered some solutions for finally handling anonymous functions, which is super awesome and long overdue. Being able to run our test suite with different JS engines would be really cool, as well as shipping some alternatives. Serialisation uses a lot of CPU in CouchDB and any experiments or adventures into finding ways to improve this would be welcome. Currently we do all of the following: browser/API (javascript native <->json) couchdb (json <-> erlang terms) couchjs ( json <-> javascript native) I'd love to see some incremental/experimental changes or tests in this space, as previous attempts got side tracked with discussion rather than shipped contributions. Providing alternate couchjs builds is relatively low-impact compared to alternative communication protocols, maybe thats a good place to start. A+ Dave
