[sugar] Importing objects from journal
Tue Sep 25 10:13:55 EDT 2007
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.
> 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  and
> > will let the user choose one or several objects from a simplified
> > journal list view.
> >  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
> > Sugar at lists.laptop.org
> > http://lists.laptop.org/listinfo/sugar
More information about the Sugar-devel