I've continued to work on the couchbase-lite-core Node.js mappings and got my implementation to a stage where nearly all APIs in C4Database.h (open / close db, get / put raw documents etc) and the key stuff in C4Base.h (logging domains, levels) to help debugging are working and there's a test suite written with near full coverage of the bindings as they expand. Still C4Document and its Fleece extensions to work through, and C4Query.h, before it makes sense to even think of using any of this for a couchbase-lite like higher level API on top of this. However, given the code already there, building these bindings is now mostly very straightforward, if tedious given the amount of C boilerplate involved.
Two questions I have come up with based on reading some of the source that I wanted to be certain about: 1. Are there any asynchronous callbacks involved in the C API level (for example from database observers) which would fire (as a feature, not a bug) on a different thread than the thread on which the database API calls are otherwise executing? This would lead to some special considerations given the V8 model of thread isolation. 2. Is it correct that for any C4Slice / C4String / ... with malloced buf to it, the C4 APIs I passed them to do not take ownership (i.e. that I am responsible for freeing it at the end I created it)? I'm creating enough of slices that I'd like to now get their memory management right. Those C4 objects that C4 APIs themselves hand and which map to objects exposed to the JS context, like C4Database *, are already memory managed seemingly alright in my wrapper (N-API provides garbage collection finalization callbacks where I free up the native resources). Matias On Tuesday, 7 November 2017 20:59:19 UTC, Matias Piipari wrote: > > For anyone interested, I've put my embryonic, experimental > couchbase-lite-node project over to this public repository: > https://gitlab.com/mpapp-public/couchbase-lite-node > > This has become a fun evening hacking project. I intend to wrap the > couchbase-lite-core C API with a Node.js API that can act as a basis for a > higher level Couchbase Lite Node.js API implementation. > > Matias > > On Tuesday, 24 October 2017 18:19:35 UTC+1, Matias Piipari wrote: >> >> Cool. I got somewhere with prototyping using what I am calling >> couchbase-lite-node without a better term (couchbase-lite-core APIs mapped >> in node, using fastcall (an ffi package alternate to node-ffi) as a basis. >> Quickly became obvious though that although that works, debugging anything >> with the bindings is painful using it (sigsegv as only error info gets old >> real fast) and it’s nice to also get compile time information of any >> further couchbase-lite-core C API changes too. So I’m starting over with >> n-api. >> >> Matias >> >> - - - - - >> Matias Piipari, PhD >> http://twitter.com/mz2 >> >> Manuscripts - A writing tool like nothing you have seen before >> http://manuscriptsapp.com >> >> On 24 Oct 2017, 17:52 +0100, Jens Alfke <[email protected]>, wrote: >> >> >> >> On Oct 22, 2017, at 5:20 PM, Matias Piipari <[email protected]> >> wrote: >> >> This sounds good. Do you follow some pattern for noting commits or >> release note entries where C API changes are introduced? >> >> >> I try to call this out in the commit message. So far it’s been informal >> because it’s just three co-workers using this API to implement CBL, but if >> there’s more development going on, we may want to establish clearer rules. >> >> Also, you can do a git diff of C/include/ to focus on changes to the API >> headers. >> >> —Jens >> >> -- You received this message because you are subscribed to the Google Groups "Couchbase Mobile" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/mobile-couchbase/6e46856a-f29a-423b-93c1-86a391e54ac4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
