Re: online desktop APIs
On Tue, 2007-04-10 at 19:49 -0400, Havoc Pennington wrote: Hi, I blogged a few days ago about the idea of an online desktop. For our initial prototypes, we've taken a pretty ad hoc approach that tends to leak Mugshot specifics in a messy and undocumented way. I brought up the idea of lots of different apps on the desktop taking advantage of online services and web sites, and we'd need clean APIs for that. I don't want to write a bunch of hypothetical APIs in a vacuum but I picked two that we are already using and cleaned them up / genericized them to illustrate the idea: http://developer.mugshot.org/wiki/Online_Desktop_API As background, the reason there are dbus APIs is that the Mugshot process is establishing a connection to mugshot.org via XMPP and sucking down a lot of information; this would be too expensive to do in every application. So the architecture is to have one or a few dedicated process(es) that go out to the Internet, and then other apps can get the info from these services. This also simplifies matters as we address offline operation and local caching, since the services can deal with it and not the individual apps. A few general concerns... (I brought these up with Havoc, but wanted to write them down here for the broader audience.) - We need to be careful to design D-BUS API's that will naturally result in efficient applications. If the D-BUS API looks like user.getProperty(name); user.getProperty(homeUrl); ... then normal displays might involve hundreds or thousands of roundtrips over D-BUS. The fact that you *could* use the asynchronous facilities of D-BUS to reduce round-trips isn't sufficient; if this is significant new way of writing applications, then the natural and convenient way of writing code has to be the recommended way as well. Does that mean that a client library is necessary? - Extending the communicated information should not require code changes at all levels, but only at the source and the destination. For example, it should be possible to extend the set of information provided by the Mugshot server to include the user's GPS coordinates, then *immediately* write a gadget for the desktop that uses those GPS coordinates to show the current weather for the user. To me, this means that a setup where we have a central desktop daemon that parses and *understands* all the information that the network server provides, and converts it into D-BUS is wrong, because it means that to add extra information, the central desktop daemon needs to be upgraded, and the D-BUS schema needs to be extended to include the new information. We should instead be looking to make the central desktop daemon transparent. It manages the connection to the server, and can add things like caching and change notification, but it doesn't actually need to understand the information that it is passing around. - When dealing with network protocols (or even D-BUS interfaces), it's far too easy to get sloppy and skip documentation or let the documentation get out of sync with the code. Documenting things in text form on a Wiki doesn't work, because it's simply far too easy to skip the step and not update the wiki. We need to have the same level of integration that we have with gtk-doc for C code, where updating the documentation is an integral part of updating the interface. - Owen ___ desktop-devel-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: online desktop APIs
Owen Taylor wrote: On Tue, 2007-04-10 at 19:49 -0400, Havoc Pennington wrote: Hi, I blogged a few days ago about the idea of an online desktop. For our initial prototypes, we've taken a pretty ad hoc approach that tends to leak Mugshot specifics in a messy and undocumented way. I brought up the idea of lots of different apps on the desktop taking advantage of online services and web sites, and we'd need clean APIs for that. I don't want to write a bunch of hypothetical APIs in a vacuum but I picked two that we are already using and cleaned them up / genericized them to illustrate the idea: http://developer.mugshot.org/wiki/Online_Desktop_API As background, the reason there are dbus APIs is that the Mugshot process is establishing a connection to mugshot.org via XMPP and sucking down a lot of information; this would be too expensive to do in every application. So the architecture is to have one or a few dedicated process(es) that go out to the Internet, and then other apps can get the info from these services. This also simplifies matters as we address offline operation and local caching, since the services can deal with it and not the individual apps. A few general concerns... (I brought these up with Havoc, but wanted to write them down here for the broader audience.) snip - When dealing with network protocols (or even D-BUS interfaces), it's far too easy to get sloppy and skip documentation or let the documentation get out of sync with the code. Documenting things in text form on a Wiki doesn't work, because it's simply far too easy to skip the step and not update the wiki. We need to have the same level of integration that we have with gtk-doc for C code, where updating the documentation is an integral part of updating the interface. Agreed, to this end, I've got a dbus-doc project going on fd.o[1], based off Jon McCann's stuff for ConsoleKit. Its still very very young, so comments and input much appreciated. I also have concerns that this seems very mudflap-oriented. It'd be nice to see some synergy going with eds-dbus. Personally I'd like to see an fd.o standard for accessing contact information. Also presence-wise we already have Galago and Telepathy, it'd be good to get a discussion going how all this fits together. Thanks, Rob Taylor [1] http://gitweb.freedesktop.org/?p=dbus/dbus-doc.git;a=summary ___ desktop-devel-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: online desktop APIs
Rob Taylor wrote: Agreed, to this end, I've got a dbus-doc project going on fd.o[1], based off Jon McCann's stuff for ConsoleKit. Its still very very young, so comments and input much appreciated. Cool! I also have concerns that this seems very mudflap-oriented. http://gcc.gnu.org/wiki/Mudflap_Pointer_Debugging ? Assuming you mean Mugshot? The point of the new API I posted is to de-mugshot things a bit so in principle another server could be substituted. (Though after talking to Owen we're already considering changing this API a lot, so the API will be more generic - essentially the Mugshot client would become more of a pass-through proxy and cache for APIs the server provides, instead of a provider of custom-written dbus APIs; the idea is that you could patch the server and patch an app, without requiring a patch to the intermediate Mugshot client thingy) Though we want to keep things cleanly engineered so someone could replace Mugshot, at the same time using Mugshot is the only practical way to get things going IMO, for a variety of reasons. Some of the major ones: - we need an open source server under the control of the development community, because web services provided by existing sites and companies aren't sufficient. We want to use what exists - say Flickr for photos - but then be able to fill in gaps. So for example, we had to write our own browser for open source apps at http://mugshot.org/applications - it's an admin'd, hosted, clustered application server instance that has both jsp and xmpp channels, and any server-side function can be rapidly added to it; doing a new server-side function from scratch has *a lot* of overhead vs. adding to Mugshot (and also has end user overhead, e.g. signing up for the new server) - because it has web-only and Windows versions, social features need not assume that all my friends use Linux - the data model of the Mugshot meta social network or whatever you want to call it is what we think we want user experience wise, vs. say a my contact database data model. For example, people choose their own photo and nick, and maintain their own addresses, you don't have to import or edit these things. - we already have major functionality slices such as tracking your friends' photos and feeds, tracking who's listening to what, partially-complete file sharing, and social application browsing/installing/launching Theoretically, a federated or peer-to-peer architecture would be better than relying on a server; but IMHO for a lot of things federation/P2P are technologically intractable or at least hard research problems. So my assumption is that we can only use P2P opportunistically when it is workable, but need a central server otherwise. It is just 1000% simpler if we start by saying here is the server the project is based on. We'll assume it exists and rely on it. It's been a huge handicap for the last several years that when coding an open source feature, there was no way to deploy and rely on server-side infrastructure, so we want to fix that. It'd be nice to see some synergy going with eds-dbus. Personally I'd like to see an fd.o standard for accessing contact information. Also presence-wise we already have Galago and Telepathy, it'd be good to get a discussion going how all this fits together. We exchanged some initial private mail with Robert McQueen on this. It is not clear to me what the answer is, it does seem to relate somehow, but I'm not really sure yet. The social network model of contacts is not quite the same as e-d-s, since people edit their own entries, rather than everyone editing their own copy of everyone else's. The Mugshot database schema does allow an overlay of per-person contacts that aren't in the social network (that don't have an account) but it does not trivially map to the way e-d-s works, though it may be mappable. Another element of the social network is groups of course. The Mugshot social network has entities in it that are people, groups, bare IM/email addresses, and RSS feeds Also involved here is that I'd like to merge buddy lists and also people on the local LAN, but not as a one-time import, rather I'm thinking these would dynamically merge when you are signed on to the IM service. When signed on we'd also want to get presence information. Telepathy can provide this, but only if people are using a Telepathy client. Right now people are using mostly Pidgin/Gaim and X-Chat instead, I would guess. So using Telepathy doesn't really get us anywhere in the short term on that front. In other words there is a chicken-and-egg problem. I'm sure this will work itself out more as we go, I think the right starting point is more top-down and starting with the essentials. I don't really expect that we can build the right ultimate API on the first try. For me, the right top-down thinking is that our user model is
Showstopper Review
another quick list of our worst current crashers. feel encouraged to take a look and to help out with fresh ideas. EVOLUTION E-D-S http://bugzilla.gnome.org/show_bug.cgi?id=334966 = Evolution crashes sometimes when closing main window still: 217 dups total, several attempts to fix this already, and some more information on the circumstances to trigger this, but no safe way to reproduce. again: if somebody can reproduce this reliably, please test the patch attached to comment 109, and see harish's comments in comment 204! http://bugzilla.gnome.org/show_bug.cgi?id=352284 = crash in camel_mime_part_construct_content_from_parser 157 dups total, 54 in the last 30 days. useful trace available in comment 96, vvaradhan is looking into this issue, but it would be great if anybody could provide an example email for this crasher. no clear way to reproduce this so far, according to 366403#c3 this crash is accompanied by evolution using lots of virtual memory. GNOME-TERMINAL http://bugzilla.gnome.org/show_bug.cgi?id=348979 = crash in Terminal. 173 dups total, no progress at all here for the last weeks. this still needs a better stacktrace. a few reporters state that this happened while opening a new terminal window/tab or applying a new theme, but there are also other descriptions around (i pasted something). perhaps somebody can help here and try to reproduce this? GTK+ http://bugzilla.gnome.org/show_bug.cgi?id=349697 = crash on Open Folder now 807 dups total, plus 170 in the last 50 days. comment 219 states that perhaps the fix for 396161 has also fixed this issue. time (gtk+ = 2.10.8) will tell, and according to the decreasing number of weekly reports for this issue, it could well be that this one has been already fixed. http://bugzilla.gnome.org/show_bug.cgi?id=363289 = gtk_icon_cache_add_icons: icon cache corruption 153 dups total, 31 in the last 30 days. good trace and even test files available (see comment 103), now if a gtk hacker (mclasen has commented on that report in the past) could pick this one up... GNOME-UTILS\logview http://bugzilla.gnome.org/show_bug.cgi?id=364106 = crash in System Log: string_get_date_string() at logrtns.c:136 169 dups total, nice trace in comment 2. looks like a trivial one (index out of bounds), and ebassi told me that he will have a look within the next days (tia). Changes/Fixes since the last review[1]: * EOG: 379919 is fixed in 2.19.x, which should also fix 320206 * EPIPHANY: 353503 is notgnome but of course still exists, but the fix for totem bug 415389 should avoid triggering this epiphany issue. * GEDIT: 354046 is fixed in 2.18.0 - the workaround was committed. thanks, andre [1] http://mail.gnome.org/archives/desktop-devel-list/2007-February/msg00301.html -- mailto:[EMAIL PROTECTED] | failed! http://www.iomc.de/ | http://blogs.gnome.org/portal/aklapper signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ desktop-devel-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: online desktop APIs
Being able to replace Mugshot-as-desktop-server is neither here nor there. Sure, from the Freedom perspective we don't want to rely on a particular server [1], but that's not what's going to really affect the desktop experience. What's important from the user experience is not having to rely on Mugshot-as-social-network. Virtually none of my friends use mugshot - they all use facebook. So what would actually make this work is server-to-server features - the desktop may only need to talk to mugshot, but mugshot needs to tie [EMAIL PROTECTED]@mugshot.org to my facebook, msn, and jabber accounts. These social networks *also* have a variety of presence information, friends, social networks, photos, RSS feeds, statuses, and so on depending on the service. I know that mugshot does more than, say, myspace. But if a user has to get all of his friends using mugshot instead of (eg) myspace, then the end result is that the user can't use mugshot. Or the online desktop. Hope I managed to get a point across in that ramble :) -- Andrew Havoc Pennington wrote: Though we want to keep things cleanly engineered so someone could replace Mugshot, at the same time using Mugshot is the only practical way to get things going IMO, for a variety of reasons. Some of the major ones: - we need an open source server under the control of the development community, because web services provided by existing sites and companies aren't sufficient. We want to use what exists - say Flickr for photos - but then be able to fill in gaps. So for example, we had to write our own browser for open source apps at http://mugshot.org/applications - it's an admin'd, hosted, clustered application server instance that has both jsp and xmpp channels, and any server-side function can be rapidly added to it; doing a new server-side function from scratch has *a lot* of overhead vs. adding to Mugshot (and also has end user overhead, e.g. signing up for the new server) - because it has web-only and Windows versions, social features need not assume that all my friends use Linux - the data model of the Mugshot meta social network or whatever you want to call it is what we think we want user experience wise, vs. say a my contact database data model. For example, people choose their own photo and nick, and maintain their own addresses, you don't have to import or edit these things. - we already have major functionality slices such as tracking your friends' photos and feeds, tracking who's listening to what, partially-complete file sharing, and social application browsing/installing/launching [1] especially since mugshot is under teh c0ntr0l of redhat, and redhat are evil and going to take over the world with killer rabbits, remember? ___ desktop-devel-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: online desktop APIs
Hi, Andrew Sobala wrote: What's important from the user experience is not having to rely on Mugshot-as-social-network. Virtually none of my friends use mugshot - they all use facebook. Definitely - the idea of Mugshot is not to replace Facebook (or the other stuff people use). It doesn't have and isn't planned to have most of those features. Mugshot is a couple different things that are relevant here: 1) it's just a server. Several of the apps that comprise Mugshot really are pretty unrelated to one another to various degrees. We can run whatever code on this server we need. There are some services such as account creation, etc. that all code on it can use. 2) it's a see everything your friends are doing online application in particular, that looks at music people are playing, blog posts, facebook activity, new photos, etc. and pulls that together into a timeline. It also has links from someone's Mugshot page to their other profiles. But it isn't intended to *replace* any of those things. I agree that getting all your friends on Mugshot is an issue to address. They don't really have to *use* Mugshot by the way, just create an account and add their facebook account info. But there are perhaps solutions to this, we've discussed for example allowing you to add your friend's facebook account to the stuff you'd see, even if your friend has never used Mugshot. Or even better, we can perhaps use the Facebook API to get your list of friends and do this automatically (not sure they export the functionality). So those would be great directions to improve things. So what would actually make this work is server-to-server features - the desktop may only need to talk to mugshot, but mugshot needs to tie [EMAIL PROTECTED]@mugshot.org to my facebook, msn, and jabber accounts. That's exactly what it is supposed to do, if I understand what you mean. There are lots of additional accounts it could tie to, and also more ways it could tie to the accounts it already ties to, but the basic idea of Mugshot is to tie to all your existing accounts. See also: http://developer.mugshot.org/wiki/Supporting_a_New_Service http://developer.mugshot.org/wiki/Where_I%27m_At_Locations The desktop should talk to stuff other than Mugshot directly also, I think; that will often be easiest. There's no reason everything has to go through Mugshot and in fact that will produce needless server load. We do as I said though need to fill certain gaps and have certain glue, which is where our own open source server is useful. These social networks *also* have a variety of presence information, friends, social networks, photos, RSS feeds, statuses, and so on depending on the service. What we can ideally do is pull together the relevant bits. For example, if you're present on any of the things with presence, we can display that. That way whether my friends use AIM or Twitter or whatever for status messages, I can still see their status. I know that mugshot does more than, say, myspace. But if a user has to get all of his friends using mugshot instead of (eg) myspace, Absolutely not the intention, we have never felt it was realistic to get people to switch social networks. It's certainly a problem right now that friends have to create a Mugshot account before you can watch what they're doing online. We should be thinking of good solutions. The no switching criteria is why we support Windows and even work with Internet Explorer, too. All your friends have to be able to use it. And yeah, we really need a Mac port for the same reason. Hope I managed to get a point across in that ramble :) For sure. I think it's a great point and the hope is that a combination of 1) supporting tracking more aspects of what people are doing on other sites and 2) supporting ways to keep up with online activity for non-account-holders and 3) other ideas people have ;-) will improve the situation. We really need help on the huge list on http://developer.mugshot.org/wiki/Where_I%27m_At_Locations by the way ;-) (including adding more to it, and adding more detail on what to watch on each service, but also of course on implementation!) One of the guiding principles of Mugshot is totally open to work with any other site - this btw is one thing our open source site does that almost no proprietary site will do ;-) it is willing to work with anything and everything. Havoc ___ desktop-devel-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
