[Sugar-devel] webified and google gears

[David Van Assche]

I cant seem to find my spec file anymore, but I based it on this:
<http://vpv.fedorapeople.org/packages/mozvoikko/mozvoikko.spec>

To briefly explain, the .xpi is basically just a zip file, so it needs
to be placed in the /usr/lib/mozilla/extensions/{somepath}/{somepath}
and unpacked there.

Last time I built gears from source there were some hickups with wrong
libraries and flags, but It wasn't too difficult. If any more help is
needed, let me know.

David

On Tue, Apr 14, 2009 at 10:24 PM, David Van Assche <dvanassche at gmail.com> wrote:
> ok, here's what I've found so far... I'll keep looking for the actual
> spec file. I dont even know if this works, its been a while since I
> looked into this...
>
> On Tue, Apr 14, 2009 at 9:53 PM, Lucian Branescu
> <lucian.branescu at gmail.com> wrote:
>> 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
>>>>>
>>>>
>>>
>>
>