On Fri, Jun 5, 2009 at 16:26, Lucian Branescu<lucian.brane...@gmail.com> wrote: > I gave up the pickling idea when I realised that XPCOM and GObject are > messy about that. > > > Activities have data and state, right? data is persistent throughout > different states and states are saved to the Journal.
Oh, by data you are referring to whatever is written in files in the ~/.sugar/default/org.laptop.WebActivity/data directory? You can write whatever you want there, but as it isn't browseable by the user, I would recommend to use it only for configuration data, cache, etc. > Browse already saves the current page, the contents of the page and > some metadata about the page. It does not however do anything special > about extension data in the mozilla profile. They are carried along as > part of the activity's data, persistent, and are the same for all > states saved in the Journal. > > I was thinking whether it is correct to have the Gears entire profile > saved to the Journal, or for that matter the entire profile of any > other extension. Hmm, I'm not sure google gears' on-disk format is the best one to store into the journal, but maybe we can start with that and then see? Regards, Tomeu > 2009/6/5 Tomeu Vizoso <to...@sugarlabs.org>: >> On Fri, Jun 5, 2009 at 16:01, Lucian Branescu<lucian.brane...@gmail.com> >> wrote: >>> 2009/6/5 Tomeu Vizoso <to...@sugarlabs.org>: >>>> On Thu, Jun 4, 2009 at 22:42, Lucian Branescu<lucian.brane...@gmail.com> >>>> wrote: >>>>> 2009/6/4 Tomeu Vizoso <to...@sugarlabs.org>: >>>>>> On Wed, Jun 3, 2009 at 22:00, Lucian Branescu >>>>>> <lucian.brane...@gmail.com> wrote: >>>>>>> Since I missed the meeting, here goes. >>>>>>> >>>>>>> I've had a really hectic past few days, with 2 exams, just getting my >>>>>>> laptop back and constantly fighting my Uni network restrictions. But >>>>>>> it's better now, finished with exams and I figured out how to trick >>>>>>> the proxies. >>>>>>> >>>>>>> I played around with a template Site Specific Browser based on Browse, >>>>>>> almost identical up to now. I think I have SSB generation mostly >>>>>>> figured out, I need to start implementing it. I will probably have to >>>>>>> either change the existing bookmark mechanism or add a new one, >>>>>>> because bookmarks (specifically bookmarklets) should be part of data, >>>>>>> not state. >>>>>>> >>>>>>> I also tried Tomeu's technique for getting Gears to work, but that >>>>>>> xulrunner bug prevents any permissions being granted. My initial plan >>>>>>> was to test Gears with GMail, but it's not quite possible right now. >>>>>>> I'll look into it, but I'd rather not have to build xulrunner. >>>>>> >>>>>> I think we can workaround the dialog sizing issue in hulahop, ping me >>>>>> in IRC and we can see what we can do. >>>>> >>>>> Sizing isn't really an issue. The permission dialog appears and is the >>>>> size I would expect, but there's nothing in it. >>>> >>>> That sounds like a problem with the gears installation (cannot find >>>> the chrome). Once you solve that, you will find that the user cannot >>>> grant privileges to the site because the dialog is too small. >>>> >>> >>> Oh. >>> >>>>>>> Also, now I'm more inclined to do the dbus functionality through >>>>>>> pyxpcom, mostly because of security issues. >>>>>> >>>>>> In my experience with Flash activities using Gnash, rather than giving >>>>>> access to the full DataStore API it's much more practical to provide >>>>>> some very simple state-saving functionality at first. If the python >>>>>> side can tell the JS side to load a buffer of data, and can ask it to >>>>>> hand a buffer to save in the DS, we can make 90% of activities work >>>>>> with very little effort. We can always make available later the full >>>>>> API or even generic DBus access. >>>>> >>>>> Saving state is not really an issue. At least current web apps are >>>>> built so that they do not lose any data if they suddenly die and some >>>>> of them also resume from where the left off. For most, it would be >>>>> enough to save the URL. >>>> >>>> Well, I was talking about saving state to the journal. >>>> >>>>> Ideally, it would be better to serialise the webview, if possible. >>>> >>>> What do you mean by that? >>> >>> I had this wild idea that I should be able to pickle the WebView and store >>> that. >> >> I'm not sure if that would work, my guess is that debugging that would >> be quite hard. Keep also in mind that there are XPCOM and GObject >> instances as part of WebView's state, so pickling all that would be a >> problem. >> >>> However, since I decided to use Browse as much as possible, I realised >>> that Browse already does all the integration with the Journal, except >>> for extensions (like Gears). So Browse should probably be fixed to >>> store the extension profiles as part of state, not data, but I'm not >>> sure if that is correct behaviour. >> >> What do you mean by extension profiles? And about state vs. data? >> >> When I talk about the journal, I use to refer to all the stuff that >> the activity stores in the journal as the "activity state". "Metadata" >> would be the structured part of the state and "data" would be a blob >> containing the rest of the state. >> >> Regards, >> >> Tomeu >> >> >>>> >>>> Thanks, >>>> >>>> Tomeu >>>> >>>>>> >>>>>> Regards, >>>>>> >>>>>> Tomeu >>>>>> >>>>>>> This >>>>>>> http://sandbox.movial.com/wiki/index.php/Browser_DBus_Bridge#Gecko_version_notes >>>>>>> would provide dbus accessibility directly to javascript and I'd need >>>>>>> to handle security around that. Since my dbus needs are limited, I >>>>>>> prefer to instead do everything python-side and inject javascript >>>>>>> objects that do simple things (notifications, sounds, etc.). Of >>>>>>> course, dbus is still a secondary objective. >>>>>>> _______________________________________________ >>>>>>> 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