[sugar] Sharing data between activities.

Carlos Neves cn
Thu Aug 23 23:32:08 EDT 2007

Eben Eliason wrote:
>     But if you don't dislike any of the now 2, but potentially more
>     activities that share images between them, you'll end up having a
>     lot of
>     wasted space, but of course the file hashing and linking would
>     take care
>     of that.
> What space would be wasted?  Like I said, I think you only need a few 
> images as a base.  For these activities you're talking about, the 
> content of the image doesn't seem to be essential to the activity 
> itself.  You could ship 3 images or so with each and let the kids 
> provide the rest. 
>     Think of 'My Own Images' like Bookmarks are on a browser. You don't
>     store the content, you don't see the whole set of available data, you
>     just mark them as 'cool'. Maybe there is tagging in the datastore
>     objects and I never crossed it? That would work really great and
>     without
>     ever needing to do special kungfu or corner cases.
> But bookmarks are created from the browser because that's where you go 
> to browse pages.  Kids can tag and star their photos when they take 
> them.  Adding a complicated file structure for managing photos inside 
> what is otherwise a very lightweight activity shouldn't be necessary. 
>  The Journal does in fact depend heavily on the notion of tagging, and 
> as mentioned there's even an integrated "starring" feature which let's 
> the kids identify their favorite things within it.
>     It's a 'personal preference' thing, the bookmarks. You really like
>     that
>     image of an XO completely dismantled, so you use it for everything...
>     but then again, maybe user tags would work better? If the user
>     feels so
>     inclined, he/she/it can tag images and apply that as a filter when
>     selecting an 'external' image.
>     There is an extra piece of information I didn't give you, which is
>     the
>     fact that images are categorized. I have a folder that holds folders
>     (categories) that holds images. You have a list of categories
>     presented
>     to you and a separate widget that holds one image of the selected
>     category and has left/right arrows to walk through the other. 'My Own
>     Images' is a special category.
> Again, I still think this is entirely over engineering the problem. 
>  There should be a few base images (even just one?) and no need for 
> this complex hierarchy or record of images (or a sidebar at all?). 
> We've also been eliminating hierarchy in many cases, and I think that 
> the "My Own Images" category is really what it's all about.  The 
> laptops are going to ship with lots of materials and a virtual library 
> where the kids can find photos (and videos, sounds, texts, etc) of 
> anything they want, so there's not much need for each activity to 
> bundle their own library of media.  When I want to do a different 
> puzzle, I could select a new one from the Journal (via drag'n'drop or 
> a chooser).  The chooser itself will only show me images in the first 
> place, likely with thumbnails, and it will have a search and filter 
> field so I can quickly type "cat" (instead of browsing through 
> categories) and select the "starred" filter to find my favorite photo 
> of my cat in a flash.
> Since we are changing the filesystem and its access so drastically, 
> we're also dedicated to making interactions with it meaningful and 
> simple for developers so that they don't have to jump through hoops to 
> do their own management unless it's essential to the activity.  For 
> the most part, the more we can take advantage of these common choosers 
> and the idea of tagging/filtering the stronger the whole system will 
> be on the whole.
> As another small tangent, the laptops depend on the notion of 
> sessions, especially in the face of potential collaboration.  As such, 
> any management except that around a particular session is unwanted. 
>  Consider this use case:  I open a jigsaw puzzle.  I start playing the 
> default image of a fish by myself, and then I share it and work on it 
> with my friend for a while.  We make some good progress.  Later I want 
> to do my own, so I start a *new* instance of the jigsaw puzzle (read 
> this as I make a new jigsaw puzzle).  On this one I drop a photo of my 
> family, and I don't share it, because it's personal.  Tomorrow, when I 
> see my friend again, I go back to the Journal and we open the puzzle 
> of the fish we were working on yesterday, continuing right where we 
> left off.
But that is the way things are right now and I don't really see how that 
relates to the problem... When I save a puzzle (or I simply close it) 
the write_file method (iirc) is called by the datastore. In it I save 
the puzzle's current state and a *pointer* to the image being used, not 
the image itself. What you are saying, if I understand correctly is that 
I should save the whole image with every pickling?
> You see, in this way I can have a bunch of different puzzles, each 
> with it's own image, and with a different set of participants, and 
> being in a different state of completion.  Each instance of the 
> activity literally *is a different puzzle* so to speak.  Even before 
> collaboration is available, this fits with our 
> multi-instance/saved-session model, and it makes it more clear why the 
> image associated with any given instance of the activity is a more 
> intimate thing, and doesn't require the overhead of lists or managed 
> sets of files at all. (This is why I suggest only a single default 
> image...there's just one puzzle in the box, so to speak.)
There is one part to collaboration which I haven't touched yet, and 
thats what to do when you restart an activity you had accessed through 
the mesh. In the current situation, it starts at the correct state, only 
as private to you, regardless of who was participation on it. This is of 
course not desirable, and I assume something is thought/done on this 
> Hopefully this example will turn your world upside down for a bit.  We 
> look at activities in a way that's quite different from many other 
> platforms.  =)
So I gather :) But being different doesn't mean everything we know is 
wrong, or we may end up like politicians, that always oppose what is 
done by the opposition, regardless of being a good thing or not...
I mean, the whole UI concept I like, and my kids love (I have a great 
test team :) ) but the whole security / safety / isolation thing is just 
a bit too much for me. It may be a non-problem in the end, but for now 
it has been nothing but a pain for me, and I suppose that's not its 
intention ;)


Carlos Neves
cn at sueste.net
> - Eben

More information about the Sugar-devel mailing list