chor(README.md): add nodejs bindings

[frank-dspeed]

Added the Offical nodejs-cblite-bindings because i saw convergences in the forums https://forums.couchbase.com/t/node-js-bindings-for-couchbase-lite/33769/3 This is a chor documentation update to make the community aware of that

[frank-dspeed]

please review @borrrden @snej

[borrrden]

FYI these bindings are in no way official. They are mostly "toy" status and a natural byproduct of creating a visual studio code plugin. I just realized that they could be used in a standalone manner and they might be educational for someone else.

[frank-dspeed]

@borrrden they are a solid foundation and they are offical in use as you sayed they are a by product of the vscode extension but we could simply move them to a indipendent repo and we could maybe simply create what is the most common in the nodejs community we create a mono repo called couchbase/node monorepo and put there everything in a folder called packages then we still publish indipendent packages most best also for the bindings i can do the chor and repo layout stuff for you. I am from the NodeJS Package Maintainance Group https://github.com/nodejs/package-maintenance/blob/main/MEMBERS.md?plain=1#L28

That would reduce your maintainance overhead as also would help the community to identify what already exists and in which state it is.

[borrrden]

I mentioned this on a parallel forum post but I'm probably using a different definition of official than you are. Yes, they are in a product that is in a marketplace, but because we don't offer any support (paid or otherwise) for it, it is considered unofficial or perhaps I should say "unsupported." I started out, actually, by creating a separate couchbase-lite-node repo but alas my node skills are not sufficient and I got frustrated and eventually collapsed everything into just what I needed. I am surely open to reorganizing it in such a way that pleases the community. The only obvious requirement is that it continue to function smoothly as a vscode plugin. There seem to be a lot of complications and restrictions around native code inside of of vscode plugin and I am worried about breaking that.

[frank-dspeed]

@borrrden i can do that for you in the new repo and for your interrest node modules (nativ) are relativ simple once you learned the rules about them and even the community is not aware about that rules often fully.

The most Importent rule at present for your case is avoid ESM .mjs That Module System is fully Async by design. And got only WiP Compat to the sync one (require) and the sync one the require implements many loaders one is the nativ one for .node modules it is the only one that works.

to reduce complexity when publishing and handling NPM Packages with nativ modules go CJS only as that is the only thing that the engine supports. Even when there exist many Modules for NodeJS's core modules that can get imported via ESM for example

example.mjs

import fs from 'node:fs' // resolves to node/modules/fs/wrapper.mjs

node/modules/fs/wrapper.mjs

import module from 'node:module'
const defaultExport = module.createRequire(import.meta)('node:fs')

export { default: defaultExport }
export * from defaultExport

is what you get internal under the hood.

as i am also Typescript and Vscode Insider i can make sure that the extension keeps working thats also in my interrest i even will port it to the open source community (theia & codium)

• https://vscodium.com/
• https://theia-ide.org/ (vscode for the cloud)

via the https://open-vsx.org/ registry that they both use it is like the microsoft marketplace but for open source eclipse and all other open source project do use that

[rajagp]

Hi @frank-dspeed Thank you for your interest in creating and maintaining a node.JS library for Couchbase Lite. That would be immensely useful for our developer community. I can follow up with you via email to discuss next steps. Is the email address on your Github account the best option?

[frank-dspeed]

@rajagp use my couchbase tagged one: [email protected]

[borrrden]

@frank-dspeed Do you still want to link to the vscode repo given the recent developments?

[frank-dspeed]

@borrrden no we can close this unmerged as i got now contact to the other lib author and he did some good things eg: he got it working with the community edition and supports also document change listners.

it will cost me a week to Analyze all pros and cons it makes no sense to release something that will not stay.

But can you give me some infos about the vscode extension? As that uses the EE isn't that a copyright violation when we ship that directly with that vscode extension as it includes fleece wich is under BSL and vscode is a cloud Product by design see vscode web and vscode server products. As Also Theia Cloud IDE and so on. ?

Can you ask your company and make sure that we can in case of couchbase-lite-node use ee or should we do couchbase-lite-node and couchbase-lite-node-ee

my main concern is that many authors are not familar with license management and they will simply use and integrate what ever is published and this will lead later to a lot of problems in the law sector for both sides.

[rajagp]

@frank-dspeed Sorry- got side tracked with some deadlines this week. I'll circle back with you by this weekend and I'll also respond to your question on BSL licensing then.

[borrrden]

Disclaimer: I am utterly unqualified to answer any of these questions from the legal stance so if differing information comes out in the future you can consider this wrong.

The BSL only applies to the source code. The CE and EE packages both have their own separate licenses. This might be the only sentence in this whole comment that I am confident in.

Regarding the vscode extension, my first notion was that we would continue to publish it to avoid EE licensing issues. I can see how that might be disagreeable though, and I'm afraid I don't have a backup plan. That's something you can continue to discuss with @rajagp . It might make sense for us to take charge of the VSCode plugin part of things, while you focus on purely node bindings. If we continue to publish, then there is no issue. I raised this point internally when we initially released the plugin and it was cleared for release. For the bindings, I think it will make sense to have separate ones for CE and EE. The C++ portion of the node bindings can be conditionally compiled to return unsupported errors for all EE calls in the case of the former.

I absolutely share your concern that you expressed about license management. I think it's very prudent to tackle this issue now, because at the very least if you make something available via npm or some other package manager then you will need to have the consumer of that package purchase a license for use with EE. For building, things are a bit simpler and would involve a "bring your own Couchbase" model of building. For CE, there is no issue, but EE would require license purchase to deploy production (commercial) software. This is much clearer in the "build your own" model, but very muddied in the package manager model. I lack both the knowledge and authority to say anything definitive about that, so I will once again encourage you to continue your discussion with @rajagp . She will be able to gather the authoritative answers from the appropriate departments.

[frank-dspeed]

@rajagp then please also clear if we are allowed to release prebuild EE Bindings the BSL question only covers current fleece builds which are inside EE and Community Edition already. I am not even Sure if any Community Edition user knows about fleece or the BSL of it.

For example i my self wanted to replace sql lite with it then i saw this BSL and even did a hardfork from the pre BSL commit to allow to build a community edition of it for my internal needs. https://github.com/frank-dspeed/fleece this is 697eedd on 3 Sep 2021

[borrrden]

Closing this as it's unclear what is happening at this point, but whatever it is, it doesn't seem to involve the README anymore 😅

[frank-dspeed]

@borrrden no readme needed and nothing usefull can be published at present but we will rework on the module system in ECMAScript Engines in general. That will simply allow more easy interaction and FFI in general so the concept of bindings need to go away anyway.

[frank-dspeed]

License

License

• You cannot bundle/distribute the CE/EE binary version with the bindings. The CBL libraries should be specified as dependencies and pulled down separately by the users. That way, the users are agreeing to T&C of EE/CE license respectively and also compliant with commercial use of BSL license
• You cannot link to any BSL licensed code (i.e. build CBL dependency and link the library).

Conclusion

You can not ship anything you need to ship links to source as also build stack

so the vscode extension and other offical builds are the only builds that are allowed while i do not fully understand if they know what they are doing because any one can take the EE vscode extension under its final license and this way skip any Couchbase License stuff like BSL for CBLite.

At present only for my private interrest my lawyers are estimating the chance that a ASM Deassemble Dump could be used as valid representation for redistribution as that code can get generated in a ton of ways the license can not cover core algos in that state anymore as it includes no patent able core algo

it uses loops and so on vector/array.