On Wed, 2008-04-02 at 11:18 +0200, Manuel Rego Casasnovas wrote: > Hi Owen, > > On Tue, 2008-04-01 at 18:24 -0400, Owen Taylor wrote: > > On Tue, 2008-04-01 at 18:54 +0200, Manuel Rego Casasnovas wrote: > > > Moreover I can configure my Big Board as I want, adding some > widgets. > > > However if a close my session an start it in other computer I don't > see > > > any change, I think that now anything is stored "online", I think > that > > > the configuration of my Big Board is stored local. > > > > Yes, the bigboard configuration is stored locally for now, and we > > only sync a small set of GConf preferences like backgrounds and > > window manager settings. It's easy to extend the GConf sync to > > cover other keys, but we don't try to sync all of GConf since that > > could lead to unexpected results... not everything in GConf really > > is a user preference that would make sense on another computer. > > What is really syncing now? > What is this small set of GConf preferences and where I can see more > about it (even source code directly)? > At the moment, what is storing Online Desktop? The code for doing the syncing is in: online-desktop/online-prefs-sync The set of preferences to sync is defined by the set of '.synclist' files in $datadir/online-prefs-sync: online-desktop/online-prefs-sync/online-prefs-sync.synclist Is the set we are syncing right now globally, which you can see is a small set of standard desktop preferences. bigboard/bigboard.synclist Has bigboard-specific extensions... right now it's local account information, but it could (and should) be expanded. > For example if I develop a GNOME application and I'd like to store some > preference variables (stored in gconf), it can be possible modify Online > Desktop to store preference variables of my application?. Yes, you just drop a .synclist file into place. > > That leads to a lot of different things: [...] > > - Their should be platform facilities that make it easy to write > > applications that get notifications about all sorts of continually > > changing information: the desktop data model. > Something like an API to develop Online Desktop applications? I don't think there is a big distinction between: "an online desktop application" "a GNOME application that uses online desktop facilities" libddm (the data model client library) is just a library that GNOME apps can use to get data from online desktop data model. > > > On the other hand, if I would like to develop an application that > stores > > > something on Online Desktop server, how I can do it? Exists any API > that > > > provides this functionality? > > > > This is something we're still developing and we'd love to work with > > some external people to figure out the best way of doing this. > > > > The most well developed way of storing things on the server right now > > is to extend the online.gnome.org database schema to cover the new > > types of data, and then use the data model to: > > > > - Retrieve this data > > - Get notifications of changes > > - Make changes to the data > > > > This is basically how all of the current data management is handled: > > your contact list, your music history, your accounts, and so forth, > but > > it is certainly requires a strong commitment to hacking on the > > online.gnome.org server (including knowledge of Java, and SQL.) > > So it probably isn't going to be the only way to do things. Other > > things that have been discussed: > > > > - Store your data in GConf, configure the online desktop to sync it. > > Possible now, but not appropriate for everything. > > > > - Add some sort of key value pair mechanism. Easy to do, not clear > > if it's better than GConf. > > > > - Allow external web services to provide data to the data model. > > > > - Just write your service as a separate service and use the > > account management part of the online desktop to store a > > reference. Possible now, though it would be easier if we allowed > > people to integrate with the online.gnome.org user database. > > I think that if my application needs to store data online, I have to use > an external web service to store this data. But I have another question, > I can store in Online Desktop server the user and password to access to > this external service? How I can do it? > I think that Online Desktop server should provides an API to store this > kind of information (something like mugshot provides now). Maybe it's > already supported, but I don't how. We're working this at the moment ... nothing that's finished enough that I can point you to it right now. > On the other hand, it is possible that my application stores its own > information modifying online.gnome.org database schema to store this > kind of information. > > What is the better option to store information? Use online.gnome.org > database or an external web service? It depends. - If you already have an external web service running, than that's easier than rewriting inside our server. - If you are familiar with and want to keep using a particular language or development tool (say, Ruby on Rails) then you are better off with an external service. The online.gnome.org server is written in Java. - If the server side component is complex (tens of thousands of lines of code), then it's better done externally. Otherwise, it may be better to do inside the online.gnome.org server; that way you don't need to maintain a separate server somewhere. > > > For example, if I like to modify a RSS reader in order that it knows > > > when an Online Desktop session is started and then gives my RSS from > a > > > Server and mark as read these feeds as read local and on my server. > And > > > later I started my Online Desktop session in other computer and I > start > > > my RSS reader, the feeds marked as read, keep marked as read. Is it > > > possible? How can I do it? > > > > For RSS feeds in particular, the best way of working on this might be > > to enhance the "Mugshot stacker" functionality to make it a better > feed > > reader. There are lots things to do there: > > > > - Show more than the first 256 characters of feeds > > - Handle embedded images (this one is Hard to do well, but we could > > do a simple job, I think) > > - Allow subscription to feeds directly for one user account > > - Combine quipping across all copies of the same feed entry. > It was only an example (an idea). > > However I'd prefer to use my habitual application to read feeds (for > example Lifera) and that this application would be able to use Google > Reader and synchronise with it (getting the user and password from > Online Desktop). Maybe it's a mistake, but it's only my idea. I'm not sure the combination of Liferea + Google Reader is coherent ... is the feed polling being done client side (Liferea) or server side? (Google Reader). What if Liferea polls a feed entry before Google Reader sees it? How does it store the "readedness" of that entry. In general, we want to avoid these complex sort of "sync" problems. So, ways of doing feed reading that I would consider consistent with the Online Desktop philosophy: - Store your Liferea subscriptions on the online.gnome.org server - Write a local client for Google Reader that uses the online desktop to store your Google account information. - Do server-side polling on the online.gnome.org server (Mugshot) > > > Finally I don't know if it's the goal of Online Desktop, or it's > very > > > far from it. I hope that someone can help me with some explanation. > > > > I hope the notes above clear things up a bit. I know it's a bit > > confusing to get it all sorted out, even for me sometimes... :-) > Thanks so much, your explanation helps me very much to understand better > Online Desktop. > > Sorry for all my questions, but I'm trying to improve my knowledge about > Online Desktop. Thanks for all the questions ... I think the answers will be useful for a lot of people. - Owen
Attachment:
signature.asc
Description: This is a digitally signed message part