Beta release of the Java implementation of dbus
hp at redhat.com
Mon Jan 1 23:08:31 PST 2007
Matthew Johnson wrote:
> * multi-threaded DBusDaemon replacement
I do wonder whether this is useful; I think the daemon is quite a bit
more complex than the protocol, and also quite a bit more
underspecified, so I'm not sure reimplementations are going to be very
compatible (at least when it comes to things like activation and
security policy). I guess someone using dbus in a non-desktop type of
context might want a pure Java daemon.
Multithreaded is the way Java IO works, but do remember that the
single-threaded bottleneck in the daemon is a guaranteed semantic; i.e.
there has to be a synchronization point that all the messages go
through, you can't parallelize message dispatch. You can parallelize
reading and writing to the sockets, but each message has to be
completely routed (assigned to outgoing queues) prior to moving on to
the next message. This is probably obvious, but since there's not much
spec, stating the obvious seems worthwhile ;-)
> - How should I support auto-creation of busses?
My best idea would be to invoke dbus-launch in the same way that libdbus
does. However, that interface to dbus-launch is not frozen, so be aware
that it might change on you.
You could also just punt on it, I think autolaunch is a corner case that
only happens when things are broken anyhow, personally.
With the pure Java daemon, you could even run the daemon in the same
process as the app, if the app is going to have its own private daemon
anyhow... not a bad idea perhaps. Seems like a nice reason to write the
> - Is there a method for detecting protocol extensions? Like alp I have
> implemented support for a single-precision float type, but it's
> unclear how to detect what the protocol in use is (particularly in a
> peer-to-peer case where there is no Hello message first which won't
> use extensions)
There's a section in the spec that describes the available ways to do
this. The clean way would be to add some kind of official
feature-negotiation thing to the auth protocol and document it in the
spec. The ugly way is the same, except the feature negotiation thing is
not in the spec and uses whatever naming convention the spec suggests
for auth protocol commands not in the spec (I don't remember).
I do find it odd that both of you guys are implementing the float type,
and nobody has ever proposed it on the list.
FWIW the rationale for omitting float is that I rarely if ever see float
in a program, because single-precision floats don't have enough
precision for most uses. Pretty much nobody uses single-precision float
unless performance is critical (maybe in 3D math?) and they're paying
strict attention to precision issues. But in those cases how likely is
it to shovel the floats over dbus? When one does have some arcane reason
to use a float, you could always push them over dbus by converting to
double or just sending them as binary data.
That's the original rationale... there's the additional rationale
post-1.0 that it would be an interoperability headache when newer
float-using apps talk to older dbus implementations... probably all the
protocol implementations would need to be able to fall back to using
double on the wire instead.
If you're going to code things so float in the program can be sent as
double on the wire (which I think is totally reasonable for languages
that have a float/double split), then why not just do that always;
allowing float on the wire is an optimization, but it's an optimization
that is unlikely to ever matter. I think the GLib bindings may even do
this already (accept G_TYPE_FLOAT and convert it to a double).
Anyway, just the background on that. The larger point is, please feel
free to propose spec extensions on the list; certainly some
feature-negotiation commands within the auth protocol would be good to
have in the spec and not ad hoc.
More information about the dbus