On Thu, Jul 02, 2009 at 11:52:01AM +0200, Bert Freudenberg wrote:
[1] contains my thoughts on a VCS based datastore rewrite - a bit fleshed out now, but still not finished. The most important part for now is that I'd like to change the find() API call to take two parameters instead of one.I'm slightly surprised you find this minor change the most important part.
Let's say the most important part that's not version related. :)I'm quite open about how much compatibility too keep, BTW - it's just that since we're breaking API in a significant way anyway we can also try to provide one that's more clear on what it does and less things "for historical reasons". E.g. the activity_id, object_id, ... are not that well defined in general [3] and also named differently in different parts of the code (uid vs. object_id). Giving better names might help activity authors understand what's going on (I for one had a hard time doing so). Preferably we'd do such changes now rather than after calling a release 1.0 and having a manifold number of activity developers (= API users).
[1] http://git.sugarlabs.org/projects/versionsupport-project/repos/mainline/blobs/master/datastore-redesign.htmlHow do you intend transfer of file ownership to be handled?
checkout:
* data store hardlinks entry into target directory
* files read-only and directories read-write for activity (=>
ensure link-breaking)
Commit is similar, now mentioned in the document as well.As to how exactly to implement the actual ownership setting, I need to talk to Michael about that. It might even get handled entirely within Rainbow (rainbow-sugarize to be exact), e.g. by creating directories with appropriate rights on startup. See also [2], Nr. 1.
Have you though about interaction with Rainbow?
For sure. :)I'd even like to run the data store isolated as well in the long run (principle of least privilege).
The only way to access meta data for a given object seems to be find()?Yes, though we might keep get() as a wrapper for compatibility or easier understanding by activity authors. But technically get() is just a special case of find(), so no need to duplicate it.
Is there metadata associated with the object in general or just in each version?For now with each version. We might choose to make some of it global later.
In update() I assume you submit the old version_id and get back the new version_id?Exactly. The workflow already described that, now the API description does as well.
And since you do not care about compatibility you should change the spelling to follow the D-Bus naming conventions:http://dbus.freedesktop.org/doc/dbus-specification.html#naming-conventions
Will check them out, thanks for mentioning! [2] http://wiki.laptop.org/go/Rainbow/Current_Situation#Implementation[3] http://git.sugarlabs.org/projects/sugar-toolkit/repos/mainline/blobs/master/src/sugar/activity/activityhandle.py#line41
CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/
signature.asc
Description: Digital signature
_______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
