Re: online desktop APIs
Hi, Now we're thinking about a different approach to this that avoids hand-coding of D-Bus APIs every time we want to add a new property or kind of info that the server can host. Wrote up notes at http://developer.mugshot.org/wiki/Extensible_Server_API Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: online desktop APIs
On 4/15/07, Havoc Pennington [EMAIL PROTECTED] wrote: Whoever is interested in the project, same as any other open source project. If someone thinks it would be fun to work on then they are welcome, if they don't then they'll work on something else. It doesn't have to be people working on GNOME right now and it doesn't have to be people from Red Hat. In fact some of the interest has been from people who are neither of those. But obviously GNOME and Red Hat developers are welcome. I don't think this general direction has to be the GNOME direction I see it as more of an offshoot like Maemo or One Laptop. I don't understand. What is Mugshot then? What is it not? To me, it is not clear what the intended audience is, if there is one. Then would it be possible to add some gaming to Mugshot? It would be pretty fun to play Gnometris against someone over the Mugshot server. Or even better, GnomeScrabble! Can you imagine how many grandmas would instantly switch to GNOME if playing scrabble was as easy as Programs - Games - GnomeScrabble?? Absolutely. This was something we looked into starting with in fact, as an initial demo of the online desktop idea, the main reason we didn't do it is that when I researched it I couldn't find a game codebase I thought I could modify in only a week or two, it looked like all of them would take more like a month or two to make them work well. Then lets start small. For example, it would be useful and fun to have GNibbles upload your high score to the Mugshot server. Then you could compare your high score with other Gnibbles players. If that works well enough you could abstract it out into a general UploadYourHighscore API suitable for all high score tracking games, Gnometris, Mines etc. Then you'd also have to solve obvious security flaws like how to prevent people from cheating on their high score. There are other games worth network-izing too, one of the best ones is Frozen Bubble unfortunately it is a single giant perl file... How about FreeCiv? Last I played it, it had big problems with server outages and to few players available to find a game. Maybe Mugshot could help with both finding players and be a stable server to play on? Or is that out of scope for Mugshot? 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!) I'm sometimes lurking in desktop-devel-list@gnome.org, does that count? :) What about game servers and message boards? Sounds good, yup. We've been meaning to add Wii ID support too... You have basically answered every single question I have asked about Mugshot with Sounds good, we will have that. :) Are there some cool and online things Mugshot is not? Also, how do you plan to bridge language barriers? An English community site is only good for native English speakers. A needed task for the mugshot.org server is to i18n-ify it; there was a short thread on this in the mugshot list archives. I think there is more to it than that. For example, in Sweden the most popular community site is www.lunarstorm.com. Naturally, to attract Swedish community people you would need to hook Mugshot up to that. For news feeds you'd like to subscribe to sites such as www.aftonbladet.se or www.idg.se instead of www.cnn.com. There are a lot of those kind of problems if you want to attract everyone. And that is only the technical part of it. For example, I don't think anyone could ever convince me to use MySpace no matter how good their site is technically. -- mvh Björn ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: online desktop APIs
Hi, BJörn Lindqvist wrote: I don't understand. What is Mugshot then? What is it not? To me, it is not clear what the intended audience is, if there is one. I talked about this in http://log.ometer.com/2007-04.html#3 (scroll down to Target Audience) I even have a not section about people I don't think would be interested. Then lets start small. For example, it would be useful and fun to have GNibbles upload your high score to the Mugshot server. Then you could compare your high score with other Gnibbles players. If that works well enough you could abstract it out into a general UploadYourHighscore API suitable for all high score tracking games, Gnometris, Mines etc. Then you'd also have to solve obvious security flaws like how to prevent people from cheating on their high score. I think that's a good goal (though I don't know how to prevent high score cheating, short of DRM-like measures, if high scores are only shown for your circle of friends it probably doesn't matter) How about FreeCiv? Last I played it, it had big problems with server outages and to few players available to find a game. Maybe Mugshot could help with both finding players and be a stable server to play on? Or is that out of scope for Mugshot? I don't think it's out of scope. You have basically answered every single question I have asked about Mugshot with Sounds good, we will have that. :) What I would say is sounds good, we could have that - I'm not saying that anyone I know of is implementing this stuff, just that I think they are worthwhile directions for design and/or implementation if people were interested. Are there some cool and online things Mugshot is not? There are lots of things it is not right now, but the point is we aren't arbitrarily limiting what we could do or would support someone in doing. Some things I'd say we don't want to do: - we don't want to replicate existing widely-used stuff, such as becoming a self-contained social network site, or becoming a photo organizer site, or adding our own online word processor; mugshot is more about being a glue or meta service to connect things - we don't care about features for certain audiences, two examples perhaps are enterprises and unix die hards who only use terminals - we don't want to do things that will bring our servers to their knees - we don't want to do things that suck from a design standpoint I think there is more to it than that. For example, in Sweden the most popular community site is www.lunarstorm.com. Naturally, to attract Swedish community people you would need to hook Mugshot up to that. For news feeds you'd like to subscribe to sites such as www.aftonbladet.se or www.idg.se instead of www.cnn.com. That's why we want to support a long list of different existing services and just glue them, rather than trying to replace what people already use. Ultimately to support more services, we'll need help from people who use those services and want them supported. There are a lot of those kind of problems if you want to attract everyone. Of course. So we start with some people and some stuff, and evolve it. Same as GNOME; I remember when GNOME was a gray rectangle that pretty much crashed on startup./in my day And that is only the technical part of it. For example, I don't think anyone could ever convince me to use MySpace no matter how good their site is technically. The beauty is that you don't have to. We should avoid any path that demands that people switch what they use. Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: online desktop APIs
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. Who are we? From your explanations I'm almost guessing that it is some combination of GNOME and RedHat. Then would it be possible to add some gaming to Mugshot? It would be pretty fun to play Gnometris against someone over the Mugshot server. Or even better, GnomeScrabble! Can you imagine how many grandmas would instantly switch to GNOME if playing scrabble was as easy as Programs - Games - GnomeScrabble?? 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. Why is that useful? 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!) I'm sometimes lurking in [EMAIL PROTECTED], does that count? :) What about game servers and message boards? Also, how do you plan to bridge language barriers? An English community site is only good for native English speakers. -- mvh Björn ___ desktop-devel-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
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
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
Re: online desktop APIs
I think that the D-BUS daemon approach can make sense, but I'm not sure it is going to be necessary for all kinds of things that might fall under the online desktop umbrella. For example if I wanted to write a little Flickr panel applet, I would probably just pick up a random Python library (e.g. http://beej.us/flickr/flickrapi/) than trying to create a daemon (with all the packaging/startup/API-design it entails) and writing my app on top of that. One major question it comes down to is - how many consumers of the data do you expect? If it's just 1, possibly two, then a daemon approach probably isn't necessary. If there are 3 or more, then it is probably a good idea. Another test critera is whether notifications are important, and whether or not the service provides a mechanism for notification. Mugshot being true for both, Flickr false for both, something like Google docs would be true for the first but not really the second (as I understand it). The D-BUS daemon approach is going to be better if both of these are true. Kind of an aside but - in terms of APIs useful for online applications, one thing that is sorely needed in my opinion is a common library for accessing cookies and http caching. We have bits of the former in the Mugshot client, but it should probably be broken out, and it would be good if it supported more browsers too. For http caching, ideally we would just reuse the active browser's cache, instead of having it per-app and stored in random places. I'm not sure if e.g. Firefox exposes a remote interface to its cache though. Neither of these things are very sexy though, admittedly. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: online desktop APIs
Colin Walters wrote: I think that the D-BUS daemon approach can make sense, but I'm not sure it is going to be necessary for all kinds of things that might fall under the online desktop umbrella. For example if I wanted to write a little Flickr panel applet, I would probably just pick up a random Python library (e.g. http://beej.us/flickr/flickrapi/) than trying to create a daemon (with all the packaging/startup/API-design it entails) and writing my app on top of that. I think that's fine, the most important place to do the dbus API thing is when there's a benefit to sharing across the apps. For example there is good reason to have single lists of people and documents On the flickr front, I doubt anyone cares if the app uses flickr directly or not, but they may care if the desktop is already displaying their flickr ID in the sidebar and on mugshot.org, but then the applet or app asks for it again. So at minimum if we add the API to get someone's account names on their services, that would be a good thing to use. Kind of an aside but - in terms of APIs useful for online applications, one thing that is sorely needed in my opinion is a common library for accessing cookies and http caching. Strongly agree. The really simple thing that would be helpful is if the standard GNOME http library (or the ones people are using, like neon or curl) was set up, by default, to use the same cookies as the browser. The Windows http library automatically uses the IE cookies and this is very helpful. We should definitely have gnome-vfs/gvfs do this, in any case. If the browsers could factor out their bookmark system so it was easily pluggable with del.icio.us or another service, that would be cool too ;-) Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
online desktop APIs
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. The same basic concern would also apply to any other non-Mugshot service that we want to take advantage of, most likely. Another aspect of this is that talking to most web service APIs is kind of a pain in the ass with weird authentication setups, XML parsing, and whatever. By adding the D-Bus layer we can make things a lot simpler for a typical app. Comments and suggestions welcome. Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: online desktop APIs
I am glad that your original blog was more than just a passing post and something that you are planning to act upon. I really agree with your thinking on the direction that the gnome desktop should take, or at least a specific Gnome Online Desktop. I have actually already started a page on the gnome wiki about it. The link is http://live.gnome.org/GnomeOnlineDesktop. And possibly a more relevant section to your post is http://live.gnome.org/CentralizedWebServicesInformationIndexer. Note that I'm no programmer or interface designer. I'm just a long time user that would like to see Gnome succeed. The ideas are still very rough but the main point is that I would like the user interaction to be that you install one plugin for each web application or service and it integrates into all of your desktop applications. From an architectural point of view that would mean exactly what you are proposing, in having an easy (generic) way for applications to integrate. I would also like to see provisions for applications to have more specific integration, but still having to install just one plugin for each web application or service. Very late, but I would like to thank everyone involved for this awesome Destkop Environment. Kyle Mitchell ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
