Roadmap?

[David Zeuthen]

Havoc Pennington said:
> 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"
>

Ok, that makes sense. I will risk some karma, though, and try to
express some of my thoughts on this. Sorry for wasting your bandwidth
with my ramblings.

So, I see D-BUS as the glue, the bridge really, that offers services
that applications consume. Today this is being done out-of-process
(standard IPC) and even out-of-the-box (over IP).

What about having a D-BUS service that is in-process? So, the method
invocations would amount to marshalling and demarshalling parameters
which fortunatly is in a binary format. I suppose that the round-trip
time is very short for this - it is comparable to scripts I think.

The application doesnt really need to know whether the service is
remote, out-of-process or in-process. The author doesnt need to link
with any libraries since libdbus would dlopen the service shared
object.

In this context, D-BUS wouldnt really be the "hub" - it would still
be a bridge to services that applications consume. The thing I am
proposing is just a more optimal way of accessing services so we
can do exciting stuff like getPicture() on a Camera device without
suffering from round-trip delays etc.

(Just an idea, please shoot it down)

> 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 would probably want this anyway as your in-process library also
want to avoid round trips for priming the cache when being initialised.

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

This makes sense. Note that IMAP actually got this getEverything()
method call more or less.

Thanks,
David