Proposing a convention for null ObjectPaths

[Havoc Pennington]

Hi,

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
    become, etc.)

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

Havoc