Proposing a convention for null ObjectPaths
hp at redhat.com
Fri Aug 10 11:14:19 PDT 2007
Here are a bunch of questions related to extending the type system, just
throwing them out there so we can get some common assumptions and
baseline as we consider such extensions.
- one thing I'd like to see is that current application code remains
unchanged, that is, for existing dbus apis that declare a
currently-valid signature, NULL is still an impossible value.
(if we allowed type "s" to suddenly be NULL for example, then all
apps would suddenly become crashable)
(and even for new APIs I think it's best to avoid nullable when
it's not needed, since it adds an extra check the app has to do,
which is why dbus doesn't support null right now)
- the macro "type system intersection" idea vs. "type system union"
question gives me some pause about allowing null integers (few languages
support nicely), vs. null strings (most languages support nicely)
(I would think this intersection vs. union question is also the
guiding principle for evaluating the other type system extensions
people have proposed. I suspect intersection is ideal for public IPC
that lots of apps might use and union is ideal for more private
usage, so tough to make everyone happy.)
(If it is not clear to people what I mean by intersection of type
systems different languages/bindings are using, vs. union of them,
I can explain further, but if it's clear I could use thoughts on
how to evaluate this tradeoff)
- what is the overall cost of elaborating the type system?
(iow, if we did 4 or 5 type system extension proposals, how much
more code are we talking about once all the bindings are looked at,
how much harder do tools like dbus-monitor and dbus-inspector
- is it valuable to fully sync the DValue format
http://live.gnome.org/DValue/Serialisation with the DBus wire
format, or does it not really matter?
(one practical importance being, as we evolve the dbus wire format,
do we need to worry about the issues that primarily matter in
a file-on-disk context and don't matter much in an IPC context.
another practical question is whether we should have one spec
or spec chapter that covers both.)
- how much do we care about compatibility?
(libdbus/dbus-daemon have to keep all the current protocol support,
which means some of the proposed changes could make a pretty good
mess out of the code by adding multiple codepaths.)
(if there are several reimplementations that don't mess with back
compat with the current protocol, then effectively as a community
we are breaking compat...
or if everyone does do back compat, it makes the same mess
I'd expect in libdbus)
(if we don't care about compat much now, when do we start?)
- how much effort will we spend on churn here, vs. how much code
and clunkiness will we save in apps?
(I think some kind of nullable values might be a big win for
apps, but some other possible type system extensions might be
more pain than gain, so this could be a case-by-case question)
Sorry for some of the big-picture questions, but we've never really
extended dbus to date, so we have to pioneer this area in some respects.
More information about the dbus