[Sugar-devel] webified and google gears

Lucian Branescu lucian.branescu at gmail.com
Tue Apr 14 14:36:15 EDT 2009


2009/4/14 Tomeu Vizoso <tomeu at sugarlabs.org>:
> On Tue, Apr 14, 2009 at 20:19, Lucian Branescu
> <lucian.branescu at gmail.com> wrote:
>> Gears is just a XUL extension, packaging shouldn't be a problem.
>
> You mean you are volunteering to package it? ;)
>
> David Van Assche already worked on it and got it pretty much working,
> but it never was submitted to fedora. Would you like to finish this
> work?
>
> Packaging work might not seem too challenging, but consumes quite a
> bit of time and is crucially important for projects like Sugar.
>

I'll have to look into that, then.

>> Also,
>> it does not require sync-ing state, web apps can store everything in
>> Gears and work in offline mode. Gears provides some integration with
>> the desktop (which can simply be ignored, it's mostly desktop
>> shortcuts and the like), an SQLite database accesible from JS and a
>> Worker (thread-like) object.
>
> Sounds good.
>
>> Using existing web technologies and standards (de facto or not) is
>> very valuable, especially for my case. I don't want to invent any new
>> technologies or techniques, just to provide a simple Site Specific
>> Browser. If I were to do so, existing web apps would have to be
>> modified and new ones would be unusual from the POV of web developers.
>
> Agreed.
>
>> For Journal integration, the entire Gears database could be store in
>> the DataStore.
>
> That would work fine, only that for example a karmized web app that
> processes images might make more sense to write a png file, so other
> activities can open it. But I don't think it's a critical point.
>

The Desktop module in Gears can access local files, with permission
from the user. So a Gears web app that deals with files should be able
to do this.

> Regards,
>
> Tomeu
>
>
>> 2009/4/14 Tomeu Vizoso <tomeu at sugarlabs.org>:
>>> Hi,
>>>
>>> I like your proposal because focuses on a problem interesting to the
>>> Sugar community and because proposes a solution that is reasonable
>>> enough to be implemented in the GSoC timeframe.
>>>
>>> But the mention of google gears concerns me a bit, since no
>>> distribution that I know is packaging it and because AFAIK it would be
>>> sync'ing state between local storage and a remote server when
>>> activities are supposed to be storing it's whole state to the journal.
>>>
>>> From my current POV, may be better to provide a (XPCOM?) component
>>> accessible from JS that provides DataStore integration. I think it
>>> could be fairly simple to do with hulahop.
>>>
>>> On the other hand, we should really find a way to have Google Gears
>>> installed alongside Sugar because many interesting sites require it,
>>> but it may be out of scope form your proposal.
>>>
>>> Regards,
>>>
>>> Tomeu
>>>
>>
>


More information about the Sugar-devel mailing list