Closed davelab6 closed 8 years ago
Datastore on the client side is not handle in a db but directly using localStorage. There is no complexity on this side for the moment. So I don't see benefit to use PouchDB (or another local DB) now.
I found https://github.com/mWater/minimongo as a similar tool for MongoDB.
I don't see benefit to use PouchDB
Currently you store data on client side using localStorage, but how do you sync this data with the Sugarizer Server?
For each user, there is a local Journal stored in the localStorage and two remotes Journal stored on the Sugarizer Server: one that only the user can see, one shared by all users on the server. Both remote Journal content are stored in MongoDB. So, there is no synchronization: each user could choose which content he want to put on the server and which content he want to share.
What about when the user works offline, and then comes online?
The user work offline in the localStorage then could put content from local Journal to the server when online again.
two remotes Journal stored on the Sugarizer Server: one that only the user can see, one shared by all users on the server.
The user work offline in the localStorage then could put content from local Journal to the server when online again.
I see that makes sense for the one that only the user can see; but what about the shared one? Can they edit that offline and sync their changes to it?
Yes. When you open something in a remote Journal, Sugarizer first do a copy in the local Journal, then open it.
NICE!! :D
It seems perhaps we have already all the capabilities that PouchDB offers 'off the shelf.'
If the Font Editor Activity GSOC is done as a Sugarizer Activity, I'll find out more about how what you have works, and be informed about if there's anything Pouch would bring :)
I see the server db is mongo. I wonder if there is something for mongo like PouchDB (which is for CouchDB on the server) so that any user input that happens offline will be queued up and synced when the user gets back online?