Great start!

[bawelter]

Hey just wanted to say awesome work on the progress. This is exactly what was needed. I was hoping to do this when I had a chance but was consumed by other work related tasks. If I can help let me know.

[bawelter]

Also if this is a pure dart package you should be able to remove the android folder I believe. Just one less thing to mess with.

[Rudiksz]

Thank you. Help is always appreciated.

There's still ways to go before it is production ready. Where do I even start?

The API is 99% complete, what still needs to be done is: 1) making the database change listeners thread safe. I just need time to refactor them to how replicator change listeners are handled. The replicator runs on a separate thread by default so I had to make the listeners thread safe and Dart isolate safe from the start.

2) refactor replicator proxy configuration to use basic C type. I found that with ffi, passing Structs created in Dart, from Dart to C, can lead to random crashes. "Flattening" everything to basic C types and creating the replicator config object on C side eliminates all the crashes. That's why the replicator constructed the way it is now.

3) implementing replicator conflict handler. This is similar to push/pull fiters so again only issue is to set aside time for the implementation and specially for testing.

4) Replicated document listeners seemed to have some bug in the C library, but they are low on my priority list so I canned them for now.

These are good first issues to start with if you'd like to get your hands dirty, and I believe they would complete the API.

Two areas that need a lot of improvement to make the package ready for prime time and impact the internals are:

• asynchronous code: currently all the Dart code is synchronous API, except the change listeners, the replicator and live queries which are run in separate C threads anyway. I didn't have any major issues yet with the app freezing or UI jank (and even then I'm not sure it's not my computer doing a hickup), but I'm testing on a small db for now. Eventually some methods should be made asynchronous either with Futures (if they are not actually computationally intensive) or separate isolates (like executing "non-live" queries). This will probably introduce some light API breakage - return values would become Futures, so I plan to do this asap.

• memory management: Well, I'm using a C library, memory leaks are definitely a thing. The library itself has reference counting and mechanisms to retain and release variables, but currently cleanup must be done manually. In a few places where it was straighforward to release resources I implemented a dispose method.

It's not a pure Dart library per se, it relies on the platform specific libraries.

I have the Windows and Android libraries built, with the windows dll bundled together with the package. For Android I would probably have to publish them somewhere and then have Gradle bundle them in the app so the package can find it. I wasted 3 days unsuccessfully before I gave up (hence the useless Android folder :)). Documentation on how to do is pretty much inexistent or irrelevant to my case.

I did test the package on Android by manually adding the .so files to the Flutter app itself and it was promising.

For iOS, macOS I have absolutely no clue, but of course would be nice to have support eventually.

Here is my fork of the couchbase-lite-C library with some custom code required for Dart, if you are interested in building for macOS or iOS https://github.com/Rudiksz/couchbase-lite-C

Currently I'm working on porting my Flutter app to Windows using this plugin, and fixing things as I go but there was not much to fix yet. I have had some crashes but I belive it's either due to some thread/memory issues between Dart and C code, or even just flutter's hotreload creating weird race conditions. It is quite stable already.

PS: probably I will create separate github issues for the things here (unless I fix them myself this weekend), but I guess this is a good summary of where I am now