intent to fork a limited version

[JohnAD]

I've found the nimongo library to be very useful and am a big fan of it. But with my current project, I need to make some breaking changes that are probably not good for the current project. So, to prevent conflict I plan on forking it and, possibly, publishing the limited version on nimble.

It is a limited version, so for the full power of nimongo, please consider using nimongo still.

Specifically, the new fork will:

• only support the async usage.
• only support configuration by the connect string with an assigned database. Essentially, it will only have the equivalent of newAsyncMongoDatabase*(u: string, maxConnections = 16) as seen in nimongo.
• will not support administrative functions, such as adding indexes or users or listing collections.

It will, however, have some additional features:

• In addition to "maxConnections" there will also be a "minConnections" parameter and the number of live connections will be dynamic rather than fixed.
• Support for a "keepalive" property for each connection. Essentially, the connections will be periodically tested to ensure they are still valid.
• A 'getNext' function for safely getting a single or subset of the connections when spawning a thread.

These additional features are for maintaining a long-running pool of connections when used in an async application such as a website using the jester library. The typical two-second delay of a new SHA1 connection to a server pretty much requires that the connections go live at server startup.

I'm not really wanting to add "another project" to my to-do list, but a high-priority project I'm working on is forcing my hand.

I'm posting this here just in case folks know of an existing work-around. Or hear if there is interested from others for this.

[JohnAD]

I've done a first push to GitHub. It is called mongopool.

In the context of a thread, it is not asynchronous, but synchronous. But it is designed specifically for threaded asynchronous applications such as Jester web sites.

So, if you are doing a batched utility or a generic app, I don't recommend mongppool. But for the specific condition of calls during threads with a pre-authenticated pool, then mongopool might be a good answer

https://github.com/JohnAD/mongopool

Despite appearance, it is not up on nimble yet. I want to debug it for a few more days.

[JohnAD]

Also not on nimble yet:

https://github.com/JohnAD/bson

I didn't want to put generic BSON support in mongopool. I have some other libraries that will be using BSON also, so I split that part off.

[JohnAD]

Both of these will be up on nimble today. They also include a credit to this repo in the README.

With this, I'll close this comment. Thanks!