On Tue, 2007-09-25 at 14:49 +0100, Henrique Ser wrote: > Hello Tomeu, all, > > Well, my next task for MaMaMedia's activities on the XO is precisely > integrating with the datastore, because we have supported puzzle images > from Paint or Camera in the past by getting them from the filesystem and > this will obviously not work anymore, not only because of the upcoming > security constraints but more simply because Paint and Camera no longer > store their files there.
Right. > So, what to do? Should we wait until there is better support, assuming > it will not take long, or do I start coding with what exists, much like > Write and Browse already do, and a simple upgrade path will be provided > once things change? If you do what Write is doing now (sugar.graphics.objectchooser), we'll make it easy for you to adapt to the new API/implementation. sugar.graphics.objectchooser implementation will change later to be a wrapper around the D-Bus service I talked before. > While we have the line open, should a puzzle based on an image grabbed > from the Journal be stored as a blob on the puzzle storage, or should we > link to it and follow whatever changes com to be? You should make a copy and store it along with the rest of your data, as we won't provide facilities for linking between objects. > Tomeu Vizoso wrote: > > This was discussed somewhat lightly a while ago. I expect the security > > people to correct me where I'm wrong. > > > > On Tue, 2007-09-25 at 13:48 +0200, Bert Freudenberg wrote: > > > >> What's the policy on accessing objects in the journal? > >> > > > > There will be a D-Bus service (perhaps a new one, perhaps will be the > > service corresponding to the Journal activity) that will offer a > > retrieveObjectFromJournal method. This method will allow some preset > > filters for filtering by Kind, Date, etc. > > > > This method will open a modal dialog similar to the overlay in [1] and > > will let the user choose one or several objects from a simplified > > journal list view. > > > > [1] http://wiki.laptop.org/go/Image:Activity_browse_handheld_navigation.jpg > > > > Now would be a good moment to discuss if we should implement this for > > FRS or later. > > > > > >> I see Write uses sugar.graphics.objectchooser which simply queries > >> the datastore. Will that work once security is enabled? > >> > > > > The current implementation of sugar.graphics.objectchooser won't work, > > but that interface could call in the future the service referred above > > instead of calling directly the DataStore. > > > > > >> Can I then store the retrieved object id in my activity instance and > >> keep that reference? Can I re-open that external object after > >> resuming my activity? Can I track changes to the object in this way? > >> How do I let the datastore know that my activity contains a reference > >> to another object, so that the other would not get discarded? > >> > >> Or do I have to copy and keep that copy in "my" datastore entry, > >> which given the limited amount of NAND would be highly undesirable? > >> > > > > We have chosen to not support links to other objects in the journal. > > This will waste space, but simplifies greatly things and we hope will > > give a better experience. > > > > This was decided expecting that differential storage and transparent > > backup to the server will reduce the impact of storage waste and that > > self contained objects will allow for easier sharing and management of > > journal objects. > > > > Tomeu > > > > > > _______________________________________________ > > Sugar mailing list > > [email protected] > > http://lists.laptop.org/listinfo/sugar > > > > > _______________________________________________ Sugar mailing list [email protected] http://lists.laptop.org/listinfo/sugar
