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 <to...@sugarlabs.org>: > On Tue, Apr 14, 2009 at 21:42, David Van Assche <dvanass...@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.brane...@gmail.com> wrote: >>> 2009/4/14 Tomeu Vizoso <to...@sugarlabs.org>: >>>> On Tue, Apr 14, 2009 at 20:19, Lucian Branescu >>>> <lucian.brane...@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 <to...@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@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