Quick questions

[Havoc Pennington]

On Fri, 2005-01-14 at 22:24 -0500, Sean Middleditch wrote:
> On Fri, 2005-01-14 at 21:43 -0500, Havoc Pennington wrote:
> > On Fri, 2005-01-14 at 23:17 +0100, Ikke wrote:
> > > I still got some troubles to fully understand the meaning of all
> > > "fields" in DBUS: the a.b.c thing, the /a/b/c thing, and the last
> > > "name" (which can be compared to a function, I guess?)
> > 
> > Service name is like a domain name. there can be multiple identifying a
> > single app.
> 
> Just as a small suggestion, Havoc, it might be a keen idea to update the
> tutorial and such on the D-BUS page instead of answering the same
> question repeatedly on the lists.  ;-)

I'm waiting to finish renaming/changing things, once we start sort of
freezing for 1.0 I'll update the docs again.

e.g. I still want to lose the word "service" which I think causes major
confusion. (Everyone thinks it implies that for each app there is a
single service name, and that methods are invoked on apps instead of
objects.)

My favorite idea today is to just call it "name"
s/AcquireService/AcquireName/ etc.

> > The object path is like a pointer or reference to an object in 
> > C++/Java/whatever
> 
> One question is why there is both a path and a service?  If services are
> like domain names then can't you differentiate between different objects
> in a service using something like org.service.object instead of having a
> separate path? 

I don't understand that; a path is an object. So every
GObject/QObject/java.lang.Object you are exporting remotely has a path.
The path-to-object mapping is inside the application. The service name
to app mapping is inside the bus.

>  What form should the object path take - domain-based
> like /org/service/object or just generic like /object ? 

Namespaced, in my opinion.

>  What if the
> service doesn't need or use any different type of objects as its just a
> very simple service with a couple methods?

Then the path is sort of annoying. We could define a default path such
as /org/freedesktop/Application perhaps.

>   Why is the object mandated
> to be in path-form instead of something app/service defined?

If you don't have a format then you can't do namespacing in any
reasonable way.

The purpose of the namespace is to allow multiple code modules in the
same process to provide different parts of the namespace. e.g. GTK+
might register some objects, and then your app might register some
objects. DBusConnection can route to the right object based on the path.

> That sort of stuff should be explained in the tutorial to help out
> people not used to this kind of architecture.

I have a diagram I posted a couple weeks ago:
http://lists.freedesktop.org/archives/dbus/2004-December/001851.html

This is intended for the tutorial. But again, I want to finish
rearranging code first.

> > An interface is just like an interface in a programming language, a type
> > that an object can implement.
> 
> Why have this instead of just saying that "service foo implements these
> methods" ? 

Take the TextDocument example. Say you have a method InsertText(). Do
you want to InsertText() into a TextEditor, or into a TextDocument?
Do you want to say there's only one document? If there are two
documents, as you might expect, then how do you specify which one to
insert text into?

The way you do that is that each document has a separate object path,
and you can invoke InsertText() on the document you want to insert text
into.

If you don't have object paths, then apps have to invent their own way
to refer to objects, for example using integer IDs or something.

>   Are interfaces attached to the object/path or the service?

The object. Look, this is just like a programming language ;-) If you
know how any of the normal languages work:

 object path = object pointer/reference
 interface = interface/abstract-base-class
 method = method

That's it... there's nothing weird here.

The "services" concept is what's confusing. I'm hoping the diagram and
renaming will help.

> Is the interface just a way to namespace between two methods with the
> same name?  Why not just combine interface and method, so you invoke
> method org.interface.method instead of two separate fields for interface
> and method?

That's how it used to work. The reason they're split is to map more
closely to language object systems.

>   Any real life examples of where interfaces are
> needed/useful?

 - introspection and mapping to real object systems
 - you don't have to specify the interface when making method 
   calls, but if it was one big string you would have to type
   the whole big string

> Again, I know the answers for these are in the lists and that it all has
> a reason, but those aren't anywhere in the documentation for someone who
> wasn't following D-BUS development for a while.

So are you going to ask on the list again or submit docs patches ;-)

Havoc