[Sugar-devel] [GSoC] progress report

[Tomeu Vizoso]

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
>>>>>
>>>>
>>>
>>
>