RFC: Annotations for object path data type
Daniel P. Berrange
dan at berrange.com
Sat Jan 14 12:28:57 PST 2006
On Sat, Jan 14, 2006 at 01:17:49PM -0500, Havoc Pennington wrote:
> There are some old posts in the archives I think about "object
> references" (what corba calls an IOR) which would roughly be bus address
> + bus name + object path iirc. With that concept you could create
> "location transparent" object references.
For reference I looked through the threads
which show a number of people have very similar use cases to me, but
thus far these discussions have never resulted in any official word
in the spec about encoding object references.
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:
> 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.
> On relative vs. absolute paths: would it be simpler to just declare that
> the object paths are always absolute? I think that was my assumption...
> I hadn't considered that people would do relative ones.
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.
|=- GPG key: http://www.berrange.com/~dan/gpgkey.txt -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- berrange at redhat.com - Daniel Berrange - dan at berrange.com -=|
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/dbus/attachments/20060114/c16ef86a/attachment.pgp
More information about the dbus