[Sugar-devel] [GSoC] progress report

[Tomeu Vizoso]

On Fri, Jun 5, 2009 at 16:26, Lucian Branescu<lucian.branescu at gmail.com> wrote:
> I gave up the pickling idea when I realised that XPCOM and GObject are
> messy about that.
>
>
> Activities have data and state, right? data is persistent throughout
> different states and states are saved to the Journal.

Oh, by data you are referring to whatever is written in files in the
~/.sugar/default/org.laptop.WebActivity/data directory?

You can write whatever you want there, but as it isn't browseable by
the user, I would recommend to use it only for configuration data,
cache, etc.

> Browse already saves the current page, the contents of the page and
> some metadata about the page. It does not however do anything special
> about extension data in the mozilla profile. They are carried along as
> part of the activity's data, persistent, and are the same for all
> states saved in the Journal.
>
> I was thinking whether it is correct to have the Gears entire profile
> saved to the Journal, or for that matter the entire profile of any
> other extension.

Hmm, I'm not sure google gears' on-disk format is the best one to
store into the journal, but maybe we can start with that and then see?

Regards,

Tomeu

> 2009/6/5 Tomeu Vizoso <tomeu at sugarlabs.org>:
>> On Fri, Jun 5, 2009 at 16:01, Lucian Branescu<lucian.branescu at gmail.com> wrote:
>>> 2009/6/5 Tomeu Vizoso <tomeu at sugarlabs.org>:
>>>> On Thu, Jun 4, 2009 at 22:42, Lucian Branescu<lucian.branescu at gmail.com> wrote:
>>>>> 2009/6/4 Tomeu Vizoso <tomeu at sugarlabs.org>:
>>>>>> On Wed, Jun 3, 2009 at 22:00, Lucian Branescu <lucian.branescu at gmail.com> wrote:
>>>>>>> Since I missed the meeting, here goes.
>>>>>>>
>>>>>>> I've had a really hectic past few days, with 2 exams, just getting my
>>>>>>> laptop back and constantly fighting my Uni network restrictions. But
>>>>>>> it's better now, finished with exams and I figured out how to trick
>>>>>>> the proxies.
>>>>>>>
>>>>>>> I played around with a template Site Specific Browser based on Browse,
>>>>>>> almost identical up to now. I think I have SSB generation mostly
>>>>>>> figured out, I need to start implementing it. I will probably have to
>>>>>>> either change the existing bookmark mechanism or add a new one,
>>>>>>> because bookmarks (specifically bookmarklets) should be part of data,
>>>>>>> not state.
>>>>>>>
>>>>>>> I also tried Tomeu's technique for getting Gears to work, but that
>>>>>>> xulrunner bug prevents any permissions being granted. My initial plan
>>>>>>> was to test Gears with GMail, but it's not quite possible right now.
>>>>>>> I'll look into it, but I'd rather not have to build xulrunner.
>>>>>>
>>>>>> I think we can workaround the dialog sizing issue in hulahop, ping me
>>>>>> in IRC and we can see what we can do.
>>>>>
>>>>> Sizing isn't really an issue. The permission dialog appears and is the
>>>>> size I would expect, but there's nothing in it.
>>>>
>>>> That sounds like a problem with the gears installation (cannot find
>>>> the chrome). Once you solve that, you will find that the user cannot
>>>> grant privileges to the site because the dialog is too small.
>>>>
>>>
>>> Oh.
>>>
>>>>>>> Also, now I'm more inclined to do the dbus functionality through
>>>>>>> pyxpcom, mostly because of security issues.
>>>>>>
>>>>>> In my experience with Flash activities using Gnash, rather than giving
>>>>>> access to the full DataStore API it's much more practical to provide
>>>>>> some very simple state-saving functionality at first. If the python
>>>>>> side can tell the JS side to load a buffer of data, and can ask it to
>>>>>> hand a buffer to save in the DS, we can make 90% of activities work
>>>>>> with very little effort. We can always make available later the full
>>>>>> API or even generic DBus access.
>>>>>
>>>>> Saving state is not really an issue. At least current web apps are
>>>>> built so that they do not lose any data if they suddenly die and some
>>>>> of them also resume from where the left off. For most, it would be
>>>>> enough to save the URL.
>>>>
>>>> Well, I was talking about saving state to the journal.
>>>>
>>>>> Ideally, it would be better to serialise the webview, if possible.
>>>>
>>>> What do you mean by that?
>>>
>>> I had this wild idea that I should be able to pickle the WebView and store that.
>>
>> I'm not sure if that would work, my guess is that debugging that would
>> be quite hard. Keep also in mind that there are XPCOM and GObject
>> instances as part of WebView's state, so pickling all that would be a
>> problem.
>>
>>> However, since I decided to use Browse as much as possible, I realised
>>> that Browse already does all the integration with the Journal, except
>>> for extensions (like Gears). So Browse should probably be fixed to
>>> store the extension profiles as part of state, not data, but I'm not
>>> sure if that is correct behaviour.
>>
>> What do you mean by extension profiles? And about state vs. data?
>>
>> When I talk about the journal, I use to refer to all the stuff that
>> the activity stores in the journal as the "activity state". "Metadata"
>> would be the structured part of the state and "data" would be a blob
>> containing the rest of the state.
>>
>> Regards,
>>
>> Tomeu
>>
>>
>>>>
>>>> Thanks,
>>>>
>>>> Tomeu
>>>>
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Tomeu
>>>>>>
>>>>>>> This
>>>>>>> http://sandbox.movial.com/wiki/index.php/Browser_DBus_Bridge#Gecko_version_notes
>>>>>>> would provide dbus accessibility directly to javascript and I'd need
>>>>>>> to handle security around that. Since my dbus needs are limited, I
>>>>>>> prefer to instead do everything python-side and inject javascript
>>>>>>> objects that do simple things (notifications, sounds, etc.). Of
>>>>>>> course, dbus is still a secondary objective.
>>>>>>> _______________________________________________
>>>>>>> Sugar-devel mailing list
>>>>>>> Sugar-devel at lists.sugarlabs.org
>>>>>>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>