[Sugar-devel] webified and google gears

[Lucian Branescu]

I don't have experience with rpm, but since much of the work is
already done, I guess packaging it wouldn't be a problem. Especially
since it would only be necessary after the SSB actually works,
although earlier can't hurt.

2009/4/14 Tomeu Vizoso <tomeu at sugarlabs.org>:
> On Tue, Apr 14, 2009 at 21:42, David Van Assche <dvanassche at gmail.com> wrote:
>> I can send over what I have... I had the rpm source file somewhere...
>> I can look for it if there is interest...
>
> Yes please, the .spec file will be a good step forward.
>
> Thanks,
>
> Tomeu
>
>> David
>>
>> On Tue, Apr 14, 2009 at 8:36 PM, Lucian Branescu
>> <lucian.branescu at gmail.com> wrote:
>>> 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
>>>>>>
>>>>>
>>>>
>>> _______________________________________________
>>> Sugar-devel mailing list
>>> Sugar-devel at lists.sugarlabs.org
>>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>>
>>
>