Re: online desktop APIs

[Owen Taylor <otaylor redhat com>]

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