[Sugar-devel] Datastore API changes (was: Re: Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting)

[Sascha Silbe]

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.html
> How 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/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: Digital signature
Url : http://lists.sugarlabs.org/archive/sugar-devel/attachments/20090702/3d05246a/attachment.pgp