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

[Gary C Martin]

On 17 Jul 2009, at 15:49, Aleksey Lim wrote:

> On Fri, Jul 17, 2009 at 03:42:57PM +0100, Gary C Martin wrote:
>> On 17 Jul 2009, at 10:11, Aleksey Lim wrote:
>>
>>> On Fri, Jul 17, 2009 at 10:48:10AM +0200, Tomeu Vizoso wrote:
>>>> On Fri, Jul 17, 2009 at 04:43, Aleksey
>>>> Lim<alsroot at member.fsf.org> wrote:
>>>>> On Fri, Jul 17, 2009 at 03:11:15AM +0100, Gary C Martin wrote:
>>>>>> 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.
>>>>>
>>>>> What do you mean exactly?
>>>>> Object chooser can pick any type of objects including
>>>>> "anything" option.
>>>>
>>>> The root of the problem is that we are uploading files, not  
>>>> entries.
>>>> Some activities store files in their entries in formats commonly  
>>>> used
>>>> and known. But others will store a json file and after upload  
>>>> nobody
>>>> knows what to do with it.
>>>>
>>>> The good news is that we have already a format for packaging full
>>>> journal entries in zip files and after downloading such an entry
>>>> bundle it will be expanded and restored in the journal will all the
>>>> metadata, etc.
>>
>> +1, had this same thought last night :-)
>>
>>>> What we would need is for a simple way to upload these bundled
>>>> entries
>>>> instead of just the file.
>>>>
>>>> Any ideas about how would look the UI like?
>>>
>>> I'm thinking about implicit behaviour,
>>> like while choosing objects for input fields in Browse
>>> we can package chosen object to bundle
>>
>> As per my other email we currently have "Activities" and "Objects"
>> in the Journal. Objects could be implicitly uploaded by Browse as
>> regular files,
>
> Objects need to be bundled as well e.g. package tags that were added  
> by
> user after downloading this object to Journal.

Well... yes I do kind'a agree... but that would make it very hard to  
work with non-Sugar users and generic file types. This is a design  
area that needs more thrashing out so I'm glad it's finally getting  
some discussion :-) The other obvious way I can see is throwing a  
dialogue at the poor user, and making them choose what gets uploaded  
(Journal bundle vs. generic file), but I almost always say NO to using  
dialogues ;-)

Regards,
--Gary