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 [1] 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 object
which 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.

[1] http://git.sugarlabs.org/projects/versionsupport-project/repos/mainline/blobs/master/datastore-redesign.html

CU Sascha


Attachment: signature.asc
Description: Digital signature

Sugar-devel mailing list

Reply via email to