Beta release of the Java implementation of dbus

[Havoc Pennington]

Hi,

Cool!

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 
Java daemon.

>  - 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.

Havoc