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 social network / buddy list, rather than Outlook-style contacts; and of course the fundamental premise of the project is that we want this info stored online primarily, rather than locally primarily. So we want as a first cut to be sure we have those properties, and then massage stuff into sharing as much code as we can with projects that don't share the assumptions. Probably we can share quite a bit. It will get easier to share code over time as we become successful, since the more experimental our "online desktop" is the less willing to take patches for it people will be ;-) Havoc _______________________________________________ desktop-devel-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
