RFC: Annotations for object path data type

[Havoc Pennington]

On Sat, 2006-01-14 at 20:28 +0000, Daniel P. Berrange wrote:
> So, this suggests a slightly different on-the-wire format. Rather than
> a single object path, instead define that an object reference is encoded 
> as a three element struct. The elments would be:
> 
>   bus address : string
>   bus name: string
>   object: object path
> 
> Then mark this struct in the introspection data with an annotation such as:
> 
>   Key: org.freedesktop.DBus.EncodedType
>   Value: ObjectReference


Right, something like that. I think you'd really need to prototype it
out and try implementing the API in some bindings and so forth.
Definitely doesn't seem like 1.0 material to me...

> > It seems like you have to confront the "memory management" issue - my
> > only advice is that the object provider code really needs to recover if
> > the client goes away without calling delete/unref...
> 
> I think this depends on the use case. The scenarios I'm encountering the
> objects being created/destroy/passed around are all global, long lived
> objects accessed by many clients, so this is no memory management issue
> to worry about. If they were transient objects, only referenced by single
> clients during the course of a 'transaction', then the memory management
> issue would need to be dealt with.

If we were going to declare an official way to autocreate proxies, I
think we'd have to deal with the lifecycle stuff. It doesn't matter in
all cases, but it certainly matters often enough.

> Yeah, probably best to ignore the idea of relative paths in the context
> of the on-the-wire encoding. I just using them as a convenience in my
> app code - if we had a formal object reference encoding format, then
> the benefit of relative object paths would disappear.

For 1.0 why don't we specify that the object path should be absolute.
Then post-1.0 we could come up with a standard way to pass around a bus
+ bus name + object triplet and also define the lifecycle of such an
object.

Or, we should consider deciding that it isn't needed; the triplet is
only required for passing an object reference between two processes,
object path by itself would be fine as long as you know the bus name or
process already. Location independent references are kind of a lot of
complexity and I'm not sure they're all that useful.

Havoc