choosing better terms for proxies and services (was: [RFC] dbus-python API (re)definition)

[Simon McVittie]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 01 Sep 2006 at 12:20:20 -0400, John (J5) Palmieri wrote:
> A lot of people, especially beginners think of proxies as http proxies.
> It is confusing.  And some people have never heard the word proxy before
> also.

Consulting dict(1)'s thesaurus, perhaps "placeholder", "surrogate" or
"stand-in" would be good words to mention in the docstrings? Hmm. Or
object names, even.

On the client^Wsubscriber side, I like the idea of the docstring starting with
"""A surrogate for a remote object accessed over D-Bus""", but I'm not sure
whether the class name should be RemoteObject or SurrogateObject.

> > On the service side, "published object" is perhaps another possibility.
> > On the client side, "remote object", perhaps?
> 
> Ok, I really like this.  The publisher/subscriber idiom is well defined.
> Remote object I like even more since it is simple and non-ambiguous.
> Perhaps we can come up with an idiom which is more transportation
> oriented though instead of publisher/subscriber.  Having a theme is not
> just cheesy flash, it helps explain things in more depth.

The thing is, we're not actually transporting objects, we're
transporting messages between them, so any metaphor where we put objects
on a bus (the public transport vehicle I mean) is inherently misleading.
(This is the problem with exporting and importing too, although that never
stopped Perl and Python, respectively, using those terms.)

It's our messages which would have to be people on a bus, which would
make objects, I don't know, buildings or companies or cities or something.
I'm not keen on that metaphor.

PublishedObject sounds appropriate on the publisher side - they're
just the same objects your app already uses, except now they're
published to the world using D-Bus. Publisher/subscriber also sounds
like it's the publisher's choice what it publishes, which is
appropriate.

"Publishing" objects also seems vaguely Web'ish, which is probably a plus.

On the subscriber side, "subscribing" is a perfect match for what signal
recipients do - perhaps we could talk about subscribing to signals,
rather than connecting to them?

A subscriber calling methods on the object it subscribes to doesn't
seem as obvious though (Letters to the Editor, I suppose :-)
and I'm not at all convinced SubscribedObject is a good name for a proxy
class.

I'd be interested to hear your thoughts on this naming (you-plural:
dbus@, not just J5), and also whether I got my glossary technically and
politically correct :-)

Regards,
	Simon

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: OpenPGP key: http://www.pseudorandom.co.uk/2003/contact/ or pgp.net

iD8DBQFE+GzcWSc8zVUw7HYRAocrAJ943x7QPafadAi1I+p9qGh+qB72YQCfVses
BZzI58TyyanYNRFzaDkbtoY=
=ZpB+
-----END PGP SIGNATURE-----