Re: [Sugar-devel] webified and google gears

[David Van Assche]

I cant seem to find my spec file anymore, but I based it on this:


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  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
>  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 :
>>> On Tue, Apr 14, 2009 at 21:42, David Van Assche  
>>> 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
  wrote:
> 2009/4/14 Tomeu Vizoso :
>> On Tue, Apr 14, 2009 at 20:19, Lucian Branescu
>>  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 :
 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@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>

>>>
>>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] webified and google gears

[Felipe López Toledo]

Hi Lucian, Tomeu Vizoso

also I pretend to use gears in my project (Karma), so, I would like to help you 
with packaging it.

Lucian, as you  I have no experience with rpm, but I think in this way we can 
do it faster.

felipe
-- 
View this message in context: 
http://n2.nabble.com/webified-and-google-gears-tp2634480p2635148.html
Sent from the Sugar Development mailing list archive at Nabble.com.

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [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 :
> On Tue, Apr 14, 2009 at 21:42, David Van Assche  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
>>  wrote:
>>> 2009/4/14 Tomeu Vizoso :
 On Tue, Apr 14, 2009 at 20:19, Lucian Branescu
  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 :
>> 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@lists.sugarlabs.org
>>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>>
>>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] webified and google gears

[Tomeu Vizoso]

On Tue, Apr 14, 2009 at 21:42, David Van Assche  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
>  wrote:
>> 2009/4/14 Tomeu Vizoso :
>>> On Tue, Apr 14, 2009 at 20:19, Lucian Branescu
>>>  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 :
> 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@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] webified and google gears

[David Van Assche]

I can send over what I have... I had the rpm source file somewhere...
I can look for it if there is interest...

David

On Tue, Apr 14, 2009 at 8:36 PM, Lucian Branescu
 wrote:
> 2009/4/14 Tomeu Vizoso :
>> On Tue, Apr 14, 2009 at 20:19, Lucian Branescu
>>  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 :
 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@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] webified and google gears

[Lucian Branescu]

2009/4/14 Tomeu Vizoso :
> On Tue, Apr 14, 2009 at 20:19, Lucian Branescu
>  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 :
>>> 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@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] webified and google gears

[Tomeu Vizoso]

On Tue, Apr 14, 2009 at 20:19, Lucian Branescu
 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.

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

Regards,

Tomeu


> 2009/4/14 Tomeu Vizoso :
>> 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@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] webified and google gears

[Tomeu Vizoso]

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@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel