[sugar] Importing objects from journal

[Tomeu Vizoso]

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
> > Sugar at lists.laptop.org
> > http://lists.laptop.org/listinfo/sugar
> >
> >   
>