arrdem

Okay. So it sounds like there is interest in and a design for "ReplacePort". Also it seems like this thread is dying down. Is there some sort of plan for throwing this project up on GitHub or somewhere else so that other people (myself possibly included) can share the load of making this happen? We've got a design document (ish... it'd be nice to see the whole thing in one place) help us help you roll an 0.1.0.

Delighted to hear that you have more experience working with this toolset than I do. Yay confidence! Known limitations! Rational choice of toolkit!

For this particular application a NoSQL family database like MongoDB is probably OK becuase most DB accesses will be file reads by ID or mod lookup by ID. Big sequential scans of the mods list would be better suited to a SQL derivitive for a number of database implementation reasons. I would caution you to steer clear of MongoDB itself however. Mongo is a primarily in-memory store, which is awesome for reads and writes since Mongo escapes a memory to filesystem synchronization on write most of the time. However this introduces obvious issues with data reliability. If your "real" datastore is a RAM cache that may or may not get synchronized to disk, what happens if the server looses power? Kiss your data goodby... Furthermore despite having a sharding system setting up sharding with Mongo is a total pain in my experience, limiting Mongo to applications for which a single monolithic server will suffice. I contend that while MongoDB may serve as a sufficient datastore for getting this project started, it is a poor choice in the long run and other datastores, especially RethinkDB offer the same features list with much stronger consistency gurantees and frankly a better management system. Just my $0.02.