Roadmap?

[Havoc Pennington]

On Tue, 2003-10-14 at 11:31, David Zeuthen wrote:
> So it's basically about moving functionality apps today use from
> libraries into objects. The nice touch is that this gives network
> transparency for free and removes library dependencies from
> applications. The bad part is of course roundtrip time / bandwidth
> needed (even on a local machine)...

This worries me - D-BUS is not a component/runtime system. 

Indulge some rambling - 

Really a library should be written in-process and then D-BUS should be
one proxy you can create for it. Component/runtime systems of varying
complexity include GObject, QObject, Python, Mono, Java. 
For some old background, http://people.redhat.com/~hp/runtime.html

This is why we're avoiding complicated type systems, defining IDL, etc.
in D-BUS: because your "master copy" is supposed to be in some real
runtime system, and D-BUS is just a way to export/interchange it. There
is no D-BUS IDL; the only IDL is in some of the bindings, where needed
by that binding. D-BUS is not supposed to be the "hub"

Some of the problems with using the network API as your master copy are:

 - every method can always throw errors or block
 - APIs can't be designed properly, because you have to avoid round 
   trips; so you end up with APIs like:
     "setEverything (in string hugeXMLDocument)"
     "dict getEverything ()"
 - you certainly can't write _everything_ with a network-style API, 
   you'll always have lightweight in-process objects such as 
   for GtkWidget; so if you try to use a network API for a component 
   system you are guaranteed to be stuck with two component systems
 - "network transparent" is just wrong; networking isn't transparent, 
   it's hard, you have to know something is on the network and use 
   different designs (e.g. leasing instead of refcounting)

Now granted, things aren't quite this simple.

 - we don't have even a prospect of a cross-desktop in-process runtime 
   :-( So you're left with a plain C library as the only option
 - people have to manually bind said plain C library.
 - you certainly do want to have nice remote D-BUS object APIs. 
   I'm just not sure this should be _the_ API.
   Things that are remote should be remote because they make sense 
   as remote, not because it was the only way to provide the API.
 - though the remote protocol is not _the_ API, it _does_ effectively 
   need to be API-stable as it's publicly exported
 - D-BUS certainly _is_ a compromise on the principle I'm trying to 
   advocate here, because if we had a shared runtime much of libdbus 
   API could be removed and dbus-specific "bindings" would not 
   be required. That is, dbus has more pieces of runtime than 
   I would like.

I'm not sure I can articulate very well the point I'm trying to make, or
even that I understand it well myself.

Here's a more concrete thought: maybe we should skip libhal to avoid
more duplicate runtime bloat, but perhaps the Qt/GLib/etc. "bindings"
should contain some implementation including things like caching, rather
than just being autogenerated stubs. In other words, maybe you should
think of your task as providing a network service/protocol and then the
various desktops will have APIs to make it simple to access that
protocol using desktop-specific APIs.

In other words, maybe use the D-BUS service/objects as if they were
something like IMAP or HTTP, treat hald like a server.

Don't know.

Havoc