Quick questions

[Sean Middleditch]

(cc'd dbus@fdo, seems to make more sense discussing this there)

On Fri, 2005-01-14 at 23:16 -0500, Havoc Pennington wrote:
> On Fri, 2005-01-14 at 22:24 -0500, Sean Middleditch wrote:
> > > 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.

Right, that's easy to understand from an OO-based application.  If I'm
just making a simple app that has no methods other than a couple things
like "is running" and that has no actual object that represents this,
what use is the object path then?  I don't myself really need
justification, but it's the sort of thing that should be in the
docs/tutorial.  Programmers are known for always wanting the "why" with
the "how" after all.  ;-)

> 
> >  What form should the object path take - domain-based
> > like /org/service/object or just generic like /object ? 
> 
> Namespaced, in my opinion.

Should be explained with reasoning for the opinion in the tutorial then.
(i.e., explain how object clashes can happen with libraries and the
ease-of-documentation benefits and all that fun stuff.)

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

Or just leave it empty, maybe?

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

Definitely should have that explanation in the docs.  ~_^

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

Righty, no problem - I figured the large code changes lately were the
reason (and a good one) for the lagging docs.

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

Hmm, so an interface is the same as an object path?  Of course if you
have /foo/document and /foo/editor the methods on each might do
something different.  The question is, since you already have these
distinct objects, what's the benefit of the interface in addition to
distinct objects?

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

An explanation would be great when the docs are updated.  A *lot* of
languages/programmers have no knowledge interfaces in general.  Not
surprising given that neither C nor C++ have any native concept of an
interface.  ;-)

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

Should be clear with the explanation you gave above.

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

Introspection stuff would be good to cover, again since a lot of
languages don't support it and many developers haven't used it.

(Heck, I still run into programmers who've been in the industry for
years that think things like deriving classes, and thus sharing code,
are just gross toy language bloat features to save lazy programmers from
a few minutes of cut-n-pasting... ::sigh::)

> 
> > 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 ;-)

Unfortunately, I only have a spectator's knowledge of D-BUS.  ;-)

I had actually planned on documenting the steps I took in the app I was
building earlier today as a D-BUS primer/tutorial.

Like I said, I couldn't even get that far since the API tutorial/docs
are so poor right now.  (That and it's Friday and I'm lazy.)  I should
note that I'm using the raw D-BUS API and not the glib/python/C#
bindings, since I was writing a very low-level service and need to keep
dependencies low.  I think if I had the option of using glib or
something the available docs and examples are probably more usable.

Do you want documentation problems in the bug tracker at this point, or
is it pointless if you're going to update soon anyhow?  I could list at
least the problems that gave me trouble.  (For one example, the
dbus_bus_get() uses a parameter of type DBusBusType, but the Doxygen
manual doesn't link to or list what the available values of that are, so
I had to dig in the headers.)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 1809 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/dbus/attachments/20050114/43782579/smime.bin