[Sugar-devel] [IAEP] Share sugar objects on a standalone server

[Gary C Martin]

On 17 Jul 2009, at 02:21, Aleksey Lim wrote:

> On Thu, Jul 16, 2009 at 08:03:15PM -0500, David Farning wrote:
>> On Thu, Jul 16, 2009 at 7:41 PM, Aleksey  
>> Lim<alsroot at member.fsf.org> wrote:
>>> On Fri, Jul 17, 2009 at 12:17:13AM +0000, Aleksey Lim wrote:
>>>> Hi all,
>>>>
>>>> One of lacks that sugar environment has is simple way to share  
>>>> sugar
>>>> objects for broad audience i.e. like scratch community has[1]
>>>> (thanks to davidmorris form #sugar).
>>>>
>>>> So, I've created [2]. Original idea was having highly integrated  
>>>> sharing
>>>> features into sugar shell but looks like we can do simple things  
>>>> first
>>>> and even utilize only Browse for browsing/download/upload sugar  
>>>> objects.
>>>>
>>>> The problem is - what web engine we should use.
>>>>
>>>> * Utilize AMO[3] engine which is used in activities.sugarlabs.org
>>>>   in that case we can create something like library.sugarlabs.org  
>>>> to not
>>>
>>> Pro:
>>> * we do not split users behaviour, they need the same experience
>>>  that ASLO requires
>>> * one common branding for activities and objects sites
>>> * AMO has sufficient(imo) functionality - reviews, ranking,  
>>> collections
>>>  and thumbs mode
>>>  https://addons.mozilla.org/en-US/firefox/browse/type:2/cat:all?sort=popular
>>> * we hack AMO code anyway - its not a problem in adding new AMO  
>>> environment
>>>
>>> Contra:
>> * Locality - In may instances the stuff created by students will only
>> be of interest to their friends, teachers, and parent.  Serving via
>> ASLO publishes the content globally.
>
> "publishes the content globally" is the original purpose for this  
> feature
> in contrast with
> http://wiki.sugarlabs.org/go/Features/Peer_to_Peer_Objects_Sharing
>
> Or you mean possibility to share objects on local servers?

Would be really good if we could just get the uploading of Journal  
entries via Browse working reliably, right now it's only certain  
simple object types (png, pdf, etc) that work reasonably. Then any one  
of the above solutions could be used at the desecration of a  
deployment (FWIW I favour wikis for this).

Need to make sure we have a clear message for Activity authors in  
providing uploadable/downloadable Journal entries with valid mime  
types, and perhaps even extensions (so passing entries through other  
OSs doesn't mangle them).

To be honest I'm not too clear of all this myself, and the testing we  
did at SugarCamp failed, and gave us a long list of todos (Browse  
upload/download name mangling was one of them).

Test case:
1) Create a new TurtleArt activity
2) Upload the new entry to the SL wiki using Browse
3) Use Browse to download the entry back to Journal
4) Resume it from Journal

This should ideally work for all Activities, then folks can actually  
start creating and distributing content/activities directly using  
Sugar, for other Sugar users.

Regards,
--Gary