[RFC] dbus-python API (re)definition

[John (J5) Palmieri]

On Fri, 2006-09-01 at 12:30 +0100, Simon McVittie wrote:
> On Thu, 31 Aug 2006 at 15:01:56 -0400, John (J5) Palmieri wrote
> 
> > As for main loop integration there is already a generic API that glib
> > uses.  This should be done for any other mainloop.  The only other thing
> > we should provide is a generic loop API for applications that wish to
> > poll or don't need a complicated mainloop.
> 
> Dafydd Harries suggests using an API compatible with that of Twisted
> (at a "duck typing" level, at least) so we can immediately use any of the
> Twisted main loops. If I do that, I'll provide at least one main loop
> implementation so dbus-python can work standalone - Twisted Core is
> quite a large thing to depend on.

Yes we are not depending on Twisted but I would like to make it easy for
them to integrate.  I'm not a big fan of Deferred methods.  They are
great for expert programmers but I think the callback mechanism we have
is much better for beginners and is powerful enough for experts.   

> > proxies and service should be renamed.  Proxy is a bad word to use and
> > so is service.  I like consumer/provider as an idiom since this is not a
> > strict one to one client/server architecture.  I'm not sure if those
> > make good module names.  export is ok, though I'm not sure if I like
> > that either.  Perhaps we should sit down and come up with a standard set
> > of vocabulary and produce a glossary.
> That would be very useful. I'm trying to avoid writing about proxies,
> services, clients and servers in the docstrings, but it's hard work!
> 
> I'm not entirely sure what your objection is to "proxy" - the real
> object to which its implementation is delegated is over in some
> other process, but what I do have is a proxy for the real object, which
> behaves the same. Or could you explain what you mean by proxy being a bad
> word?

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.

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



I'll comment on the glossary later.

> 
> > Signal registering and registering is a tricky subject.  Right now we
> > have two ways of doing it.  Placing a match rule on the connection or
> > connecting to a signal from a proxy.  The proxy method is really bad and
> > needs to go away since it blocks methods (only on the objects and not
> > the interfaces) from having that name and the object must be around
> > before you can actually connect to it.
> 
> I must admit I hadn't spotted this, since in Telepathy we always use the
> connect_to_signal method on the Interface wrapper.
> 
> Surely you should be able to create a proxy for a remote object that
> doesn't actually exist yet, and have it work OK until you try calling a
> method?
> 
> > Proposal is to have one set of
> > APIs for registering signals listeners on a connection.  In this
> > scenario you can pass in a proxy and it will pick up all of the needed
> > info.  The connection will listen to name_owner_changed signals and
> > register and unregister match rules based on flags such as "if service
> > changes connect signal to new service", "drop listener on change",
> > "follow first connected service" or "service must be present when I
> > register".  The current match rule format can also be used with the same
> > flags.  Lifecyle of listeners are tied to the connection and dictated by
> > the flags but rules should be able to be removed in other ways such as
> > by id.
> 
> I note with amusement that despite deprecating the terms, you still talk
> about services and proxies because they're the clearest way to express
> what you mean :-)

That is because we know what we are talking about :-).  My job with
these bindings is to be not just a kick ass production binding but also
a great way to learn D-Bus.

-- 
John (J5) Palmieri <johnp at redhat.com>