[Sugar-devel] Turtle Art on Activities.sugarlabs.org

[Aleksey Lim]

On Thu, Feb 25, 2010 at 01:26:15PM -0600, David Farning wrote:
> On Thu, Feb 25, 2010 at 12:57 PM, Aleksey Lim <alsroot at member.fsf.org>wrote:
> 
> > On Thu, Feb 25, 2010 at 12:08:41PM -0600, David Farning wrote:
> > > The other day during an infrastructure meeting, Walter brought up some
> > > thought on how to enable kids to exchange Turtle Art projects....
> > >
> > > Alsroot has been thinking about how to do this through a.sl.o since he
> > > became the activities.sugarlabs.org code maintainer.
> > >
> > > The high level view is that someone can easily upload Turtle Art
> > creations
> > > to somewhere and then they, or others, can go to a portal to download
> > other
> > > Turtle Art creations.
> > >
> > > Client side, this would require:
> > > 1. Adding a widget to either the journal or the TA activity to upload the
> > TA
> > > Bundle.
> > > 2. Adding a TA bundle installer to handler TA Bundle downloads.
> > >
> > > Server side, this would require:
> > > 1. A place to accept TA bundle uploads.
> > > 2. A search-able place from which to download TA bundles
> > >
> > > We have some similar systems we can look to as examples.
> > > 1. Scratch -- Scratch has an upload button and users can download scratch
> > > projects from --  http://scratch.mit.edu/galleries/browse/newest
> > > 2. ASLO --  Users upload XO bundles via a web interface and download via
> > a
> > > web interface.
> > >
> > > My initial instinct is to see if ASLO can be adopted to fit this need.
> > > Primarily because we have it, it works, and it is scalable.  On the other
> > > hand, if the only tool in one's toolbox is a hammer, everything looks
> > like a
> > > nail. (How is that for over using clichés and buzzword?)
> > >
> > > Considerations:
> > > ASLO rocks:)
> > > ASLO can be adapted to handle various file types.  For example:
> > > https://addons.mozilla.org/en-US/firefox/browse/type:3
> > > https://addons.mozilla.org/en-US/firefox/browse/type:2
> > >
> > > Each file type can have a separate look and feel.
> > >
> > > Is the activity creation and upload process too complicated for young
> > users?
> > >
> > > Moving forward:
> > > Would it be possible to journal or TA widget which:
> > > 1.  Walks the student though a upload wizard.
> > > 2.  Combines the TA project into a into a bundle with the metadata
> > generated
> > > in the wizard.
> > > 3.  Sends the bundle to activites.sl.o/uploads
> > >
> > > Would it be possible to setup/adapt ASLO to:
> > > 1. Handle TA files types.
> > > 2. Accepts TA bundles+metadata uploads and inserts them into the review
> > > queue.
> >
> > At the end there could problem, current AMO workflow stuck to web uploading
> > UI
> > only, so we'll have to get rid of uploaders UI and use only browsing part
> > (thus will have to not trivial patching AMO).
> >
> > >
> > > david
> >
> > there is also another way, implement it only in special activity
> > http://idea.olpcorps.net/drupal5/ideatorrent/idea/19
> >
> > --
> > Aleksey
> >
> 
> I think we are talking about the same thing.  I don't know understand the
> journal well enough to understand if it should be a separate activity,
> widget in TA, or Widget in the Journal.  But a good starting point might be
> a client side library (ALSO) activity which can push a bundle+meta data.  It
> will be an easier task creating a separate activity and proving it works
> rather than going straight to a journal feature.

Idea was just to do all things in activity and reusing only sugar
methods - telepathy(and if TP won't be good for big trafic, reuse lower
net levels) e.g. somthing what Behavior Vehikel suggests but instead of
deamons, use TP bot(s) that will look like regular sugar users for
others - it will look like "Library" user with shared Library instance
in net view. Thus w/o any web coding at all, just pure python and
sugar's TP.

The idea is that we don't have many web coders involved(I guess) and
supporting PHP/etc based projects would be overkill(supporting ASLO
doesn't take many PHP coding but w/ new library.sl.o ASLO patch will be bigger).

> From a design point of view, I am thinking that the library would either
> wrap a [XO|TA|Unified] bundle in (yet another) layer of meta data or the
> current bundle could be extended to include the necessary library meta data.
> 
> Once the bundle arrives at the server, we could extend the existing bundle
> checker to extract the new meta data and insert the bundle into ASLO.
> 
> This gives users the ability either use the web interface or library
> activity.
> 
> david

-- 
Aleksey