[sugar] Squeak / Etoys RPMs

[Ian Bicking]

Marco Pesenti Gritti wrote:
>>> Remember, we're not starting from a desktop of discrete files which you
>>> need to open.  Stuff in the journal will save what activity you last
>>> worked on something with, and that's how it will know how to get back to
>>> it.
>>>     
>>
>> What about files that were not created on an OLPC, such as oggs,
>> theoras, pdfs, or other media?  I'm writing an RSS reader for OLPC, and
>> it downloads files contained in RSS enclosures.  If there's no mimetype
>> database on the system, it seems to cut olpc off from the rest of the
>> world's content.
>>   
> 
> The problem of the compatibility with external content is a real one and 
> something we will have to think about hard. There are two ways to go 
> about it.
> 
> 1 Decide on abstract basis that we need a file type - application 
> association -> Imagine use cases for it and on the base of these define 
> the exact requirements -> Implement a mime system.

I find it hard to avoid this entirely.  For instance, imagine we have a 
flashcard activity (not too much of a stretch).  It seems like an 
obvious implementation to put flashcard data on the web somewhere, as 
type application/xml+x-flashcard (or whatever), and then import the data 
when that data type is encountered through a browser.

(Question: if so, does the browser query the user about what to open, or 
does the activity automatically get opened with the data and the 
activity should query the user about what to do?  In the case of 
importing data, *some* confirmation should happen somewhere.  But only 
the activity really knows what the data might be used for, so only the 
activity can ask for an accurate confirmation.)

> 2 Define the user experience, i.e. figure out how we want to integrate 
> external content inside activities in concrete (for example, what do we 
> want to happen when the user click a link to a pdf file in the browser?) 
> -> Architect a simple system that can satisfy these requirements -> 
> Implement it

I don't see how we can reasonably justify specially setting up a 
customized system for dealing with flashcard data.  Setting up special 
sharing mechanisms for every activity also seems difficult.

In the case of flashcards, I'd imagine the application would be both 
authoring tool and testing at the same time.  But then I would imagine 
you would either manually upload the data to a wiki, or the activity 
would have some automatic way to upload it to some wiki you've already 
specified as your "home" wiki.  But from there I think it would be best 
if it really was just embedded in the wiki.  So the activity wouldn't 
have to build in a flashcard data browser, it wouldn't have to provide 
all the necessary context for the data, or any of that -- just uploading 
(maybe), and rely on all of a wiki's natural talents to provide the rest 
of the structure.

> IHMO all that the first approach can bring is an over-engineered system 
> and a disastrous user experience.

I think this all seems rather abstract because the journal/storage 
system has not been spec'd out or implemented.  Once that happens I 
expect these issues to become more prominent.  That said, perhaps it is 
best we defer this conversation until then.


-- 
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org