Re: GNOME online desktop - (some of the possible) next steps
Awesome! I've been looking at doing DBUS binding for Pyro, but I'd gladly use yours instead. I don't really understand why you'd expose Firefox's HTTP stack over dbus, or allow DOM manipulation using the same. What do you have in mind? -Alex On 7/23/07, Ian McKellar [EMAIL PROTECTED] wrote: On 7/23/07, Havoc Pennington [EMAIL PROTECTED] wrote: - investigate how HTTP state of browser can be used by any app I'm working on exposing Firefox's HTTP stack over DBus. Should be handy. With this is should also be possible to expose as much browser state as desktop apps might need - right up to grease-monkey-like interaction with web sites. I've basically got the beginnings of a DBus-XPCOM bridge. It seems to kind of work a little bit for the tiny subset of types that I've written the marshaling code for. It's implemented as an XPCOM module that could be installed by an extension or installed system-wide in /usr/lib/firefox/components When it's demoable I'll throw my git tree up and post some binaries. Ian -- Ian McKellar http://ian.mckellar.org/ +1 415 867 9255 [EMAIL PROTECTED]: email | jabber | msn ianloic: flickr | aim | yahoo | skype | linkedin | etc. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME online desktop - (some of the possible) next steps
On 10 Aug 2007, at 17:45, Bryan Clark wrote: I'll try to put together a mockup or two for a new background chooser that incorporates this. Right now my current mockup could be called a mashup between the background chooser and the screensaver dialog as it has pieces of both. I had a quick think about this during the week as well, as Alberto was bugging me :) Trying to keep things as simple as possible, my first attempt was: http://www.gnome.org/~calum/bg-feed.png Background images that have come from a feed are just tagged with a little RSS emblem, sorted in with your local background images. Whenever you use a syndicated image as your background, it's cached locally for future use[1], at which point the feed emblem may disappear (or change?) to indicate that it's no longer a transient image that will disappear from the dialog at some point in the future. Tooltip gives you more information about where the image came from: http://www.gnome.org/~calum/bg-feed-tooltip.png The new dropdown at the top just offers choices of things like single background (the current behaviour), random from selected, random from feeds, random from all backgrounds. The 'random' choices would change your background periodically. No UI for setting the rate of change at the moment, but I'm sure that would be trivial :) The 'Edit Feeds' button would open whatever centralised feed editor somebody might like to devise... Cheeri, Calum. [1] And/or its URL pushed to your online desktop background storage service :) -- CALUM BENSON, Usability Engineer Sun Microsystems Ireland mailto:[EMAIL PROTECTED]Java Desktop System Team http://blogs.sun.com/calum +353 1 819 9771 Any opinions are personal and not necessarily those of Sun Microsystems ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME online desktop - (some of the possible) next steps
Alberto Ruiz wrote: 2007/8/9, Bryan Clark [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: Hi ~ (so late... email problems) In the video I saw of your prototype I believe it makes perfect sense to simply store the URI of a person's background / theme from the new a.g.o such that if they logged in from a new machine that setting would be preserved and restored. I don't quite understand which URI are you referring to, you mean the http URI? Yes, something like that. What I'm really getting at here is that if my background is saved as http://art.gnome.org/backgrounds/281/; then no matter what machine I'm using the Desktop could retrieve my background via the online desktop server service. It seems that there is a lot of interest in adding the subscribing feature to the theme thing, so I would like to dig a bit on it. There two reasonable of use cases that I can think of: a) John would like to have the themes available at art.gnome.org/gnome-look/whatever http://art.gnome.org/gnome-look/whatever in the appareance dialog (backgrounds/themes/fonts?). b) John likes surprises, john would like its desktop background to change every day/week/moth for the best rated/more popular/random from one of his feeds. So there are a couple of problems here. First one it's syndication, I would like to centralize the feed syndication as a DBus service, this is easy to achieve, since basically would mean, wrapping Mark Pilgrim's feedparser.py into a DBus service. I think this might be helpful for others applications that want to use other kind of feeds such as podcasts. I don't know if you need to create a service to do this. You really only need something to wake up every so often and grab feeds. But if a service can do that for you then maybe that's what you should use. I'll try to stick to the interaction storyboards and mockups :) On case 'a)', I would ask for media feeds to the DBus service, (that would just be a namespace check) and then download the thumnails and I would use those thumnails with an RSS emblem on the appearance On case 'b)' I would show a checkbox and a combo box on the background tab to allow surprise me mode and the frequency (per day, week...). Open questions: - Who downloads the media? The control center? Something else? When? I'm open to suggestions. I did an experiment with something like this a while back called background channels [1]. I think you can offer a background / theme subscription in the same UI as the one you offer local backgrounds in. It really just takes some proper positioning of the subscription vs. the single choice. For instance if you call the subscriptions Theme Subscriptions and separate them from themes that won't be changing you can begin to tell the story of the differences. Then you just need to be helpful and informative when you're updating someone's theme / background such that they aren't surprised or annoyed. I'll try to put together a mockup or two for a new background chooser that incorporates this. Right now my current mockup could be called a mashup between the background chooser and the screensaver dialog as it has pieces of both. ~ Bryan [1] http://clarkbw.net/blog/2005/05/06/background-channels/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME online desktop - (some of the possible) next steps
Calum Benson wrote: On 10 Aug 2007, at 17:45, Bryan Clark wrote: I'll try to put together a mockup or two for a new background chooser that incorporates this. Right now my current mockup could be called a mashup between the background chooser and the screensaver dialog as it has pieces of both. I had a quick think about this during the week as well, as Alberto was bugging me :) Trying to keep things as simple as possible, my first attempt was: http://www.gnome.org/~calum/bg-feed.png Background images that have come from a feed are just tagged with a little RSS emblem, sorted in with your local background images. Whenever you use a syndicated image as your background, it's cached locally for future use[1], at which point the feed emblem may disappear (or change?) to indicate that it's no longer a transient image that will disappear from the dialog at some point in the future. Tooltip gives you more information about where the image came from: http://www.gnome.org/~calum/bg-feed-tooltip.png The new dropdown at the top just offers choices of things like single background (the current behaviour), random from selected, random from feeds, random from all backgrounds. The 'random' choices would change your background periodically. No UI for setting the rate of change at the moment, but I'm sure that would be trivial :) The 'Edit Feeds' button would open whatever centralised feed editor somebody might like to devise... Cool! Sounds we're on the same track for how the system interacts. Here's the mockup I was working on... enlarged to show how powerful it is! Perhaps we can combine ideas were appropriate and come out with something. http://www.gnome.org/~clarkbw/images/backgrounds-dialog.png I kept the current list format of [thumb] /info/ [thumb] /info/ [thumb] /info/ I planned to use the right hand side for a preview mode, maybe showing the background on your desktop. The idea is to be more explicit about scaling images, hoping it would be helpful for showing the screen size vs. the image so you can easily fix stretching and other scaling aspects. While I made my mockup dialog fairly large I don't actually think most of the browsing will be done in here. I'm making the assumption that the dialog is designed for choosing from a set of backgrounds or subscriptions you have already and that the web site will allow you to pick new individual backgrounds to download (which then appear in the dialog). When trying to design this once before, people wanted to be able to choose an individual image from a subscription and just keep that one as their background. I made a button for keeping current image from the subscription, however in practice you find that people really want the image that was just replaced and not really the current one. I think there are a lot of ways to make that better, but one easy one was to assume the web site allowed people to dig into a subscription and click [get this background!]. Cheers, ~ Bryan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME online desktop - (some of the possible) next steps
On Thu, 9 Aug 2007, Bryan Clark wrote: snip An excellent advantage that the online desktop server project has in being open source is that it doesn't have to re-implement any other existing service. MySpace and other proprietary sites will continually purchase or build new extensions (like video and photo services) to bring into their fold. Our blessing (and our curse) is that we'll Mostly true about the lock in of these sites but it sounds like you might be unfamiliar with Facebook. Unlike most of the other social not-working sites Facebook have opened up their software (to what extent I'm not sure) and are benefitting from all kinds of third party applications http://developers.facebook.com/opensource.php The wealth of third party extensions are making it easier and easier to aggregate all kinds of bits and pieces from other services on facebook, to my mind gradually becoming more like mugshot (or at least how I perceive mugshot). ... but that is somewhat beside the point. -- Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME online desktop - (some of the possible) next steps
Hi ~ (so late... email problems) Alberto Ruiz wrote: 2007/8/8, Havoc Pennington [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: Rodrigo Moya wrote: On Sun, 2007-07-22 at 10:57 -0400, Havoc Pennington wrote: Hi, Some thoughts on near-term goals and steps to get things rolling (for those who want to play): ... I miss the 'shared storage' thing in your list, like moving the themes/icons/backgrounds from art.gnome.org http://art.gnome.org to be part of online.gnome.org http://online.gnome.org. Any near future plans for that? I don't know of anyone working on anything like that yet. That's not an easy task, AGO3 (the art.gnome.org http://art.gnome.org web app) is being written at the moment, a feed mashup on online.gnome.org http://online.gnome.org might work there and maybe some API to handle ratings and popularity, but throwing the whole work of AGO3 to start from zero on o.g.o seems a pretty bad idea to me. An excellent advantage that the online desktop server project has in being open source is that it doesn't have to re-implement any other existing service. MySpace and other proprietary sites will continually purchase or build new extensions (like video and photo services) to bring into their fold. Our blessing (and our curse) is that we'll always be offering choice of services from many different providers (flickr for photos, youtube for videos). The online desktop server service should be pointing to the user chosen service from a list of services that provide the best experience. Since AGO3 is being written to provide an online storage for backgrounds and themes, the online desktop would simply point to the storage locations provided by art.gnome.org. In the video I saw of your prototype I believe it makes perfect sense to simply store the URI of a person's background / theme from the new a.g.o such that if they logged in from a new machine that setting would be preserved and restored. ~ Bryan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME online desktop - (some of the possible) next steps
2007/8/9, Bryan Clark [EMAIL PROTECTED]: Hi ~ (so late... email problems) In the video I saw of your prototype I believe it makes perfect sense to simply store the URI of a person's background / theme from the new a.g.o such that if they logged in from a new machine that setting would be preserved and restored. I don't quite understand which URI are you referring to, you mean the http URI? It seems that there is a lot of interest in adding the subscribing feature to the theme thing, so I would like to dig a bit on it. There two reasonable of use cases that I can think of: a) John would like to have the themes available at art.gnome.org/gnome-look/whatever in the appareance dialog (backgrounds/themes/fonts?). b) John likes surprises, john would like its desktop background to change every day/week/moth for the best rated/more popular/random from one of his feeds. So there are a couple of problems here. First one it's syndication, I would like to centralize the feed syndication as a DBus service, this is easy to achieve, since basically would mean, wrapping Mark Pilgrim's feedparser.pyinto a DBus service. I think this might be helpful for others applications that want to use other kind of feeds such as podcasts. On case 'a)', I would ask for media feeds to the DBus service, (that would just be a namespace check) and then download the thumnails and I would use those thumnails with an RSS emblem on the appearance On case 'b)' I would show a checkbox and a combo box on the background tab to allow surprise me mode and the frequency (per day, week...). Open questions: - Who downloads the media? The control center? Something else? When? I'm open to suggestions. ~ Bryan -- Un saludo, Alberto Ruiz ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME online desktop - (some of the possible) next steps
Rodrigo Moya wrote: On Sun, 2007-07-22 at 10:57 -0400, Havoc Pennington wrote: - the application-install stuff at http://mugshot.org/applications needs a bit of work to support non-Fedora distributions; it's written to allow that, but we really need volunteers to add Ubuntu etc. can you just point it to official ubuntu/opensuse/etc packages? There's some work to do that, Owen would know better exactly what. But for example the client app adds a browser extension that knows how to install a package by name, and that extension needs to know what to do on ubuntu and opensuse. Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME online desktop - (some of the possible) next steps
Rodrigo Moya wrote: On Sun, 2007-07-22 at 10:57 -0400, Havoc Pennington wrote: Hi, Some thoughts on near-term goals and steps to get things rolling (for those who want to play): ... I miss the 'shared storage' thing in your list, like moving the themes/icons/backgrounds from art.gnome.org to be part of online.gnome.org. Any near future plans for that? I don't know of anyone working on anything like that yet. Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME online desktop - (some of the possible) next steps
Le mercredi 08 août 2007 à 12:07 -0400, Havoc Pennington a écrit : Rodrigo Moya wrote: On Sun, 2007-07-22 at 10:57 -0400, Havoc Pennington wrote: - the application-install stuff at http://mugshot.org/applications needs a bit of work to support non-Fedora distributions; it's written to allow that, but we really need volunteers to add Ubuntu etc. can you just point it to official ubuntu/opensuse/etc packages? There's some work to do that, Owen would know better exactly what. But for example the client app adds a browser extension that knows how to install a package by name, and that extension needs to know what to do on ubuntu and opensuse. I'll be happy to help for integration with Mandriva / urpmi ;) -- Frederic Crozat [EMAIL PROTECTED] Mandriva ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME online desktop - (some of the possible) next steps
2007/8/8, Havoc Pennington [EMAIL PROTECTED]: Rodrigo Moya wrote: On Sun, 2007-07-22 at 10:57 -0400, Havoc Pennington wrote: Hi, Some thoughts on near-term goals and steps to get things rolling (for those who want to play): ... I miss the 'shared storage' thing in your list, like moving the themes/icons/backgrounds from art.gnome.org to be part of online.gnome.org. Any near future plans for that? I don't know of anyone working on anything like that yet. That's not an easy task, AGO3 (the art.gnome.org web app) is being written at the moment, a feed mashup on online.gnome.org might work there and maybe some API to handle ratings and popularity, but throwing the whole work of AGO3 to start from zero on o.g.o seems a pretty bad idea to me. Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Un saludo, Alberto Ruiz ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME online desktop - (some of the possible) next steps
Alberto Ruiz wrote: That's not an easy task, AGO3 (the art.gnome.org http://art.gnome.org web app) is being written at the moment, a feed mashup on online.gnome.org http://online.gnome.org might work there and maybe some API to handle ratings and popularity, but throwing the whole work of AGO3 to start from zero on o.g.o seems a pretty bad idea to me. It seems odd to me too, if the end result would be the same thing already on art.gnome.org, no reason to redo. Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME online desktop - (some of the possible) next steps
Hi, On 7/24/07, Bastien Nocera [EMAIL PROTECTED] wrote: On Mon, 2007-07-23 at 15:10 -0400, Havoc Pennington wrote: - sync of browser state (history, bookmarks, cookies, passwords), like Google Browser Sync but open source and integrated with everything else (e.g. no need to log in to Google separately for browser sync and big board) Bryan mentioned this to me, and the best approach to take right now would probably be to get Google to Open Source this piece of code. That would at least mean time isn't wasted whilst a volunteer shows up. I asked Robert to look into this last week, and he says that there's no plan to open source the browser sync in the short to medium-term but wasn't able to give much of a justification. When I pressed him as to whether or not it was fundamentally un-open-sourceable, he said that it wasn't and that the reason was more roadmap based. So it looks like we'll need to duplicate the work here, although putting additional pressure on Google to open source it is also a good idea. Joe ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME online desktop - (some of the possible) next steps
On Sun, 2007-07-22 at 10:57 -0400, Havoc Pennington wrote: - the application-install stuff at http://mugshot.org/applications needs a bit of work to support non-Fedora distributions; it's written to allow that, but we really need volunteers to add Ubuntu etc. can you just point it to official ubuntu/opensuse/etc packages? -- Rodrigo Moya [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME online desktop - (some of the possible) next steps
On Sun, 2007-07-22 at 10:57 -0400, Havoc Pennington wrote: Hi, Some thoughts on near-term goals and steps to get things rolling (for those who want to play): ... I miss the 'shared storage' thing in your list, like moving the themes/icons/backgrounds from art.gnome.org to be part of online.gnome.org. Any near future plans for that? -- Rodrigo Moya [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME online desktop - (some of the possible) next steps
Bryan Clark wrote: Havoc Pennington wrote: Hi, An issue with the mockups is that the outside accounts list is shown as private, but since we're sharing one database with Mugshot, if you add those accounts they will be public over on mugshot.org Basically the public/private rules can't differ between gnome.org and mugshot.org if the same database is storing the info. By using the same mugshot database we end up with almost the inverse of the mockup. (I knew there was another reason to have the public / private section drawn up!). And this inverse world, which exists on mugshot.org, can be reflected in the o.g.o mockup by having everything listed in the public section, except for your email address and aim which stays in the private section. Ok, I've gone from a couple pages to pretty much all of the pages necessary [1] for getting the basic online desktop account system working. The home page needs all the work now. During the transition period it seems the home page might be mostly read-only and you can use the http://mugshot.org/account page for adding and removing accounts. ~ Bryan [1] http://www.gnome.org/~clarkbw/designs/online/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME online desktop - (some of the possible) next steps
Havoc Pennington wrote: Hi, Jeff Waugh wrote: quote who=Havoc Pennington - modify mugshot.org/applications (to become online.gnome.org/applications) to support web apps - make online.gnome.org and mugshot.org work as OpenID providers Quick Q about these so I have my facts straight: Do you intend for mugshot to be a branded 'frontend' to online.gnome.org? Which data will be stored on either side? Or will the users and data be separate and/or federated? There is probably a short and a long term answer. Right now what we're doing is just adding more jsps to mugshot.org that will be served when the server is reached from online.gnome.org. These jsps will not have the Stacker, just an edit my account page and a login/signup page. They will have GNOME branding instead of Mugshot. Bryan is making mockups. Yay mockups! For now I've been putting the mockups in the Online Desktop wiki, but they can easily be transfered around to a place that makes more sense. I think it's also on my TODO list to move things over to live.gnome.org... There are only really 2 pages right now, but I'm keeping a Web Site Mockup [1] category for the login [2] and home [3] pages. The design goal was to keep everything really simple in look and implementation (funny how they're related!). There are a couple of tertiary pages that also need to be made, I'm working on finishing the ideas around the home page and then I'll likely get to those. Cheers, ~ Bryan [1] http://online-desktop.org/wiki/Category:Web_Site_Mockup [2] http://online-desktop.org/wiki/Image:GNOME_Online_Desktop_Login_and_Signup_Mockup.png [3] http://online-desktop.org/wiki/Image:GNOME_Online_Desktop_Home_Mockup.png ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME online desktop - (some of the possible) next steps
Bryan mentioned this to me, and the best approach to take right now would probably be to get Google to Open Source this piece of code. That would at least mean time isn't wasted whilst a volunteer shows up. Thats one of the reasons I have not tackled this in Conduit - Google open sourcing it is the best solution. The other reason was Firefox 3 will change the game because it stores everything in a SQlite DB. This is easier to parse from my perspective, but any work now will be wasted because I would sooner have to rewrite it later anyway. John -- Bastien Nocera [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME online desktop - (some of the possible) next steps
Havoc Pennington wrote: Hi, An issue with the mockups is that the outside accounts list is shown as private, but since we're sharing one database with Mugshot, if you add those accounts they will be public over on mugshot.org Basically the public/private rules can't differ between gnome.org and mugshot.org if the same database is storing the info. By using the same mugshot database we end up with almost the inverse of the mockup. (I knew there was another reason to have the public / private section drawn up!). And this inverse world, which exists on mugshot.org, can be reflected in the o.g.o mockup by having everything listed in the public section, except for your email address and aim which stays in the private section. ~ Bryan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME online desktop - (some of the possible) next steps
Hey, Thought I would weigh in with the state of Conduit, what it can do, and my roadmap of sorts. At the bottom is a little discussion of .Mac and other things. Firstly, what Conduit can do today Photo sync with F-spot, Picasaweb, Flickr, Smugmug File Sync with Box.net, gnomevfs volumes Contact Sync, iPod, gnomevfs volumes via VCards Basically ATM I am working on Better OO DBus interface following SyncML support (a DBus controlled syncml deamon) And more stuff, volunteers also welcome: - investigate how HTTP state of browser can be used by any app - lots of BigBoard productization/polish stuff to make it more usable - hack on AbiWord, F-Spot, other desktop apps to use the info from the server in useful ways Could you explain a little more on this point. For example Conduit currently does photo sync for F-Spot to the above mentioned sites. It also has various other ways to get photos into these services, behaving nicely in situations where a photo you upload once using F-Spot you then try and upload again from a folder (i.e. it skips it or updates the remote copy). In the Upload sense I don't yet see the role of mugshot/online.gnome.org in this other than storing the notion of my Flickr username is foo and my password is bar. This has benefits for Conduit because I can then skip that whole configuration step, instead going ahead and pulling that data down from o.g.o. Unless you are suggesting that a user uploads his photos to o.g.o which then pushes them out to $OTHER_SITES (which i think is a terrible idea, o.g.o servers doing 2x the data transfer to put a photo on Flickr for example) - integrate online photo sites into gnome background properties and screen saver (choose a flickr photo for your background, etc.) To continue from above. Now in the download sense I see o.g.o has benefits. Acting as a central store of knowledge like User has Flickr friends called foo and bar. In this case if (for example) a user wanted to Sync his/her friends Flickr photos with their iPod then Conduit could ask o.g.o for their friends user ids which would avoid the user having to explicitly tell conduit who their friends are. This is good. If you are thinking of data flowing differently to what I describe then please explain. - modify mugshot.org/applications (to become online.gnome.org/applications) to support web apps - store encrypted gnome-keyring on the server - facebook application that merges your Mugshot stacker into the facebook event feed While I remember it have you seen http://wiki.developers.facebook.com/index.php/Open_Source_Applications_Terms_Of_Service_Problem To some extent this is why I have not yet commit ed the Facebook photo uploader for Conduit I have been working on. - right now the default online desktop config has google calendar in big board and evo calendar attached to gnome-panel clock, fix this - make online.gnome.org and mugshot.org work as OpenID providers Application Preferences, Conduit had application preference synchronization a while ago but I took it out to work on other things and because other than a gnomevfs volume there was no way to get it between a user's two computers. If you are going to run a Daemon to push non contact data to o.g.o then consider using Conduit. The architecture these days is pretty good. If that suggestion is unacceptable then why not solve this problem lower in the stack like e-d-s-sync is. What about a gconf-sync that does the same thing on a users gconf preferemces (or an opt-in subset of them). As for dot files in a users home directory, isnt that a broken non GNOME way to store application prefs anyway? - stuff I forgot Our thought in the office here is to somewhat focus on the server side since it's a little bit scary and others would take a long time to ramp up on it. So if there's server-side stuff you need for the client-side feature you want to hack on, let us know. Discussion of .Mac and its relevance. One of the major architectural difference between OpenSync, Conduit and .Mac is that .Mac stores it 'truth' db on the .Mac server. The truth DB is basically object foo is related to object bar (i.e. this photo has been uploaded to flickr with this id). This is good for a variety of reasons, mostly that it makes it easier to solve situations like User A trying to sync/upload the same photo to flickr from two computers (sorry to once again use a Flickr example...). Currently Conduit and OpenSync get around this in various ways, basically using some sort of 'Slow Sync' mode to pull down every object from both sides and compare each one. What I would love to have is the ability to do this within the mugshot data model. Attaching the concept of two items being related to one another. Maybe for performance reasons I would pull the truth db down prior to a sync, then push it back to o.g.o at the end. Maybe i would do a http query for each local piece of data I
Re: GNOME online desktop - (some of the possible) next steps
Hi, An issue with the mockups is that the outside accounts list is shown as private, but since we're sharing one database with Mugshot, if you add those accounts they will be public over on mugshot.org Basically the public/private rules can't differ between gnome.org and mugshot.org if the same database is storing the info. Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME online desktop - (some of the possible) next steps
On Mon, 2007-07-23 at 15:10 -0400, Havoc Pennington wrote: - sync of browser state (history, bookmarks, cookies, passwords), like Google Browser Sync but open source and integrated with everything else (e.g. no need to log in to Google separately for browser sync and big board) Bryan mentioned this to me, and the best approach to take right now would probably be to get Google to Open Source this piece of code. That would at least mean time isn't wasted whilst a volunteer shows up. -- Bastien Nocera [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME online desktop - (some of the possible) next steps
On 7/22/07, Havoc Pennington [EMAIL PROTECTED] wrote: - to immediately have a GNOME server I am thinking we could take http://mugshot.org/account and create a version with a different theme and stick it at http://something.gnome.org/account Hi my.gnome.org - adel ps, try explain GOD project in one paragraph, less than three lines, something my mom can understand ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
online.gnome.org [was Re: GNOME online desktop - (some of the possible) next steps]
On Sun, 2007-07-22 at 12:02 -0700, Jeff Waugh wrote: quote who=Havoc Pennington - Jeff said he would set up online.gnome.org with mediawiki and we'll move online-desktop.org there. (maybe online.gnome.org should be the end user server for creating accounts and stuff, and we should put this on online-wiki.gnome.org or something?) Clarification: I raised the idea of running a service on online.gnome.org (and more abstract stuff on api.gnome.org), but suggested that wiki stuff happen on live.gnome.org... though I'll service your MediaWiki desires if absolutely necessary. I don't think we should 'fork' the wiki for much the same reasons we shouldn't 'fork' the choice of desktop-related discussion forum. Sorry. 8) Yeah, I don't see Moin sucks as a reason to have a separate wiki, even though Moin does, in fact, suck (*). We'll bite the bullet and integrate our content into live.gnome.org. online.gnome.org sounds like a good name for the user service web pages; unless I hear screaming and wailing, I'm just going to go ahead and repoint it at the mugshot.org servers, and we'll start working on a Mugshot-debranded, GNOME-branded version of the relevant parts of the site. Perhaps however, if we're approaching this with All Seriousness, we might consider having (at least) the entry point on www.gnome.org itself... Keeping www.gnome.org as a marketing page is probably the right thing for the forseeable future; we can add login links or whatever when things get more mature. - Owen (*) To avoid being accused of drive-by calumny against Moin, my primary complaints would be ugliness (Moin themes are better or worse, but they are all ugly), the category system, and the use of WikiWords for page titles. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME online desktop - (some of the possible) next steps
Hi, We did an in-person huddle and here is the list. Stuff we are working on today: - set up online.gnome.org with GNOME theme version of mugshot.org/account etc. - Havoc making jsps - Owen messing with CNAME config - design for online.gnome.org server flavor - Bryan - document desktop data model - Owen - fix up offline cache and reconnect handling for the Mugshot client and BigBoard - Owen - fix some problems the server is having, such as del.icio.us connection and the AIM bot - Marina - cook up some scripts for making a release of GNOME Online Desktop, develop plan for 0.1 release - Colin - RPM package updates/scripting - Colin - figure out moving stuff from svn.mugshot.org to gnome.org - some combination of Owen and Marina Stuff that is higher priority that we are thinking of doing next, volunteers welcome: - create wiki presence on live.gnome.org - shut down google group and suggest d-d-l instead - merge more outside networks (AIM, Facebook, etc.) into the contact list - allow combining contacts from separate networks (this person on Facebook is the same as this AIM) - sync of browser state (history, bookmarks, cookies, passwords), like Google Browser Sync but open source and integrated with everything else (e.g. no need to log in to Google separately for browser sync and big board) - add login via jabber/gtalk and OpenID in addition to current email or AIM And more stuff, volunteers also welcome: - investigate how HTTP state of browser can be used by any app - lots of BigBoard productization/polish stuff to make it more usable - hack on AbiWord, F-Spot, other desktop apps to use the info from the server in useful ways - modify mugshot.org/applications (to become online.gnome.org/applications) to support web apps - store encrypted gnome-keyring on the server - facebook application that merges your Mugshot stacker into the facebook event feed - right now the default online desktop config has google calendar in big board and evo calendar attached to gnome-panel clock, fix this - make online.gnome.org and mugshot.org work as OpenID providers - integrate online photo sites into gnome background properties and screen saver (choose a flickr photo for your background, etc.) - stuff I forgot Our thought in the office here is to somewhat focus on the server side since it's a little bit scary and others would take a long time to ramp up on it. So if there's server-side stuff you need for the client-side feature you want to hack on, let us know. Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME online desktop - (some of the possible) next steps
quote who=Havoc Pennington We did an in-person huddle and here is the list. Looks great, and thanks very much for making the effort to post it here. :-) - Jeff -- OSCON 2007: Portland OR, USAhttp://conferences.oreillynet.com/oscon/ Try Thunderbird, like Evolution but without all the features. - Pia Waugh ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME online desktop - (some of the possible) next steps
quote who=Havoc Pennington - modify mugshot.org/applications (to become online.gnome.org/applications) to support web apps - make online.gnome.org and mugshot.org work as OpenID providers Quick Q about these so I have my facts straight: Do you intend for mugshot to be a branded 'frontend' to online.gnome.org? Which data will be stored on either side? Or will the users and data be separate and/or federated? Thanks, - Jeff -- linux.conf.au 2008: Melbourne, Australiahttp://lca2008.linux.org.au/ She sped into the parking lot, the door flew open and there she was, dressed only in a black bathing suit and sunglasses. I got in and she reversed straight into another car. Classic Carine. - Stephen Gan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME online desktop - (some of the possible) next steps
Hi, Jeff Waugh wrote: quote who=Havoc Pennington - modify mugshot.org/applications (to become online.gnome.org/applications) to support web apps - make online.gnome.org and mugshot.org work as OpenID providers Quick Q about these so I have my facts straight: Do you intend for mugshot to be a branded 'frontend' to online.gnome.org? Which data will be stored on either side? Or will the users and data be separate and/or federated? There is probably a short and a long term answer. Right now what we're doing is just adding more jsps to mugshot.org that will be served when the server is reached from online.gnome.org. These jsps will not have the Stacker, just an edit my account page and a login/signup page. They will have GNOME branding instead of Mugshot. Bryan is making mockups. The backing database is still the same, so an account on online.gnome.org is the same as one on mugshot.org and the data is in one big soup. What this gives us is online.gnome.org by the end of the week or so and BigBoard etc. can start to be powered by online.gnome.org. Longer term we can split things up more fundamentally. The idea is that Mugshot is the stacker/watch what's happening online site and will be parallel to / on similar footing with other third party web sites we integrate with. online.gnome.org will have /applications, storage for user settings, your avatar/name, and other important desktop backend features. Basically online.gnome.org will be required for online desktop (but not for GNOME, if you just stick to classic desktop mode), while mugshot.org will be the stacker app and you only use it if you want the stacker feature. But mugshot.org isn't core in any way, it's just another web site we integrate with - though an open source one. It isn't 100% clear yet how the details work out but that's the general idea that makes sense to me. The long-term location of the servers isn't clear yet, and we'll probably also want to make the servers a test case for a shiny new Free Terms of Service / Open Service Definition that isn't defined yet. The two items you quoted from my post, in more detail, are: - right now we package some web apps like GMail in the online-desktop module, adding .desktop files and MIME handlers and so forth, but we don't track these web apps on mugshot.org/applications. So we should track them, probably based on browser title (but never sending the browser title to the server) - there are Java libraries for OpenID; we should make your profile page on both mugshot.org and online.gnome.org act as an OpenID provider, so people can use these for OpenID if they want. Also, this would let us federate with something like the abicollab site, potentially, *waves hands wildly* Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME online desktop - (some of the possible) next steps
quote who=Havoc Pennington Right now what we're doing is just adding more jsps to mugshot.org that will be served when the server is reached from online.gnome.org. These jsps will not have the Stacker, just an edit my account page and a login/signup page. They will have GNOME branding instead of Mugshot. Bryan is making mockups. The backing database is still the same, so an account on online.gnome.org is the same as one on mugshot.org and the data is in one big soup. What this gives us is online.gnome.org by the end of the week or so and BigBoard etc. can start to be powered by online.gnome.org. Right, that's a good short term solution. The long-term location of the servers isn't clear yet, and we'll probably also want to make the servers a test case for a shiny new Free Terms of Service / Open Service Definition that isn't defined yet. ... and I think a lot of this will depend on GNOME Foundation + Advisory Board discussions about how we'll work with AB partners, branding, etc. Thanks, - Jeff -- Ubuntu Live 2007: Portland, OR, USA http://www.ubuntulive.com/ Web development with PHP is like injecting pure rust with a high-pressure hose. For pain relief. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
