[sugar] Multiple documents

[Bert Freudenberg]

On Jul 27, 2007, at 12:43 , Tomeu Vizoso wrote:

> Bert,
>
> I was replying to Erik's request and that is a totally different one
> from yours, in my opinion.
>
>> From what I understand, you are asking about how to handle different
> instances of the same activity and what relationship exists with their
> journal entries. Eben answer did not clarified your doubts?

I think I understand the intended behavior. I think it is  
insufficient for anything non-trivial, though I cannot provide hard  
facts because no one could try that part out yet because it has not  
been fully implemented. I know a somewhat similar system which allows  
to do more and more efficiently, so that's what I'm basing my  
suspicions on.

> What Erik is asking is about storing several objects inside one single
> journal entry. In his case, several photographs taken inside a single
> Record session (activity instance).

What if these should be available separately even if taken in one  
session? Why is this so different from several etoys projects created  
in one session which should be resumable separately?

> Perhaps I'm just not understanding the relationship between the two
> requests. Please explain if so.

The Sugar, Journal, Datastore and Rainbow designs all influence how  
activities function, how they interact, how they are implemented, how  
they store and retrieve data etc. And that is just the core, it even  
leaves out the really hard parts like how collaboration across  
machines works.

Besides, my rant wasn't aimed directly at you or the other coders  
working their, err, working really hard on getting something  
shippable. It's just that the only kind of response we usually get is  
"well, it's not implemented yet, do this or that for now" without  
anybody thinking (or maybe caring to tell others) about the actual plan.

- Bert -

> Thanks,
>
> Tomeu
>
>
> On Fri, 2007-07-27 at 12:23 +0200, Bert Freudenberg wrote:
>> Seriously folks, this is not just a request for an API extension.
>>
>> This is *begging* for the non-trivial aspects of the Sugar
>> environment to be fleshed out, at least in writing, if not in code.
>> We're hopping from trial to trial with patchy interim solutions. And
>> this how many months before the kids will have to use this stuff?
>>
>> Even just this one particular issue: The idea of having kids just
>> stop and resume activities is a great one. But I believe that not a
>> single non-trivial activity for now resumes to exactly the state it
>> was in when stopped. Maybe etoys could come close soon, but only
>> because etoys projects were designed from the beginning to be just a
>> snapshot of the current UI - and have been refined over several years
>> and thus are indeed comparable to what Sugar aspires to. Note this is
>> not a "Python vs. Smalltalk" debate, Etoys is just the system I'm
>> most familiar with so I take that as example - my view is necessarily
>> colored by what I'm working on.
>>
>> The questions of how multiple activity instances are handled in Sugar
>> remains open. And even the way it is handled now is going to be
>> replaced "soon" with those security containers which from what I
>> heard yet appear to make it even harder to create efficient
>> solutions. In the earlier days of Sugar it appeared as if an activity
>> implementation would be allowed to manage its instances on its own.
>> Step by step this has been made harder. Now it appears to be required
>> that every instance is a separate process that starts and lives on
>> its own in its virtual container. Which is way inefficient, I
>> seriously hope I misunderstand intentions. But requests for detailed
>> plans have not been answered either.
>>
>> Sorry for the rambling, but it appears as if everyone is so immersed
>> in their problems at hand that nobody takes time to step back and
>> look at the big picture. I've been following the public discussions
>> for almost a year now, I'm trying to soak up every bit of information
>> I can get, I've even been at the OLPC headquarters for direct
>> discussion, but still I feel lost. Yes I read the source, and I even
>> documented what I found, thank you. It's not helping for the big
>> picture. How anyone could expect external developers to contribute
>> anything significant is beyond me.
>>
>> - Bert -
>>
>> On Jul 27, 2007, at 9:15 , Tomeu Vizoso wrote:
>>
>>> Hi Erik,
>>>
>>> I suggest that if the datastore API is not enough for your needs,
>>> open a
>>> ticket in trac requesting for multiple file by entry support to be
>>> added
>>> to the DS API.
>>>
>>> By now, remember you can just put a set of photographs inside a tar
>>> file
>>> and send that to the DS.
>>>
>>> Regards,
>>>
>>> Tomeu
>>>
>>> On Thu, 2007-07-26 at 19:35 -0400, Erik Blankinship wrote:
>>>> Was my question so easy that it didn't need a response?  :-)
>>>>
>>>> Seriously...  how should activities save/serialize multiple  
>>>> files for
>>>> correct indexing/viewing in the Journal?  We need an answer
>>>> yesterday.
>>>>
>>>>
>>>> On 7/25/07, Erik Blankinship <erikb at mediamods.com> wrote:
>>>>         I am wondering if there is an answer yet to this question
>>>> from
>>>>         about a month ago?
>>>>
>>>>         On 7/12/07, Bert Freudenberg < bert at freudenbergs.de> wrote:
>>>>                 If I understand the Sugar philosophy correctly, we
>>>>                 won't have
>>>>                 multiple documents per activity. If we want to have
>>>>                 multiple
>>>>                 documents opened at the same time, these would be
>>>>                 multiple instances
>>>>                 of the same activity.
>>>>
>>>>                 Is this the case?
>>>>
>>>>                 And if so, what would one activity instance have
>>>> to do
>>>>                 to create a
>>>>                 new instance?
>>>>
>>>>                 - Bert -
>>>>
>>>>
>>>>                 _______________________________________________
>>>>                 Sugar mailing list
>>>>                 Sugar at lists.laptop.org
>>>>                 http://lists.laptop.org/listinfo/sugar
>>>>
>>>>
>>>
>>
>>
>>
>>
>> _______________________________________________
>> Sugar mailing list
>> Sugar at lists.laptop.org
>> http://lists.laptop.org/listinfo/sugar
>