Hi!After reading the recent threads about Journal / data store and the IDs used by them the big picture is much more clear now, thanks! I've adjusted by datastore redesign proposal  accordingly and would like to submit it for review now. It's not clear a full redesign is The Right Thing to do now, but I'd rather like to specify what it should look like, not what steps to take next towards it.
There's an important design decision that's still open:Is the asynchronous API design useful enough to warrant more complex implementation? - DBus operations can be run asynchronously so UI responsiveness shouldn't be
an issue - For save() calls activity needs to wait for result (containing new version_id) before it can invoke save() again for the same objectwhich can take quite some time if save() is sync - especially if other
activities are saving at the same time.Making the API fully asynchronous is the cause for much of the complexity of my proposal, but if we eliminate the queueing the response times for write accesses and checkout() can be very long even for unrelated operations.
CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/
Description: Digital signature
_______________________________________________ Sugar-devel mailing list Sugarfirstname.lastname@example.org http://lists.sugarlabs.org/listinfo/sugar-devel