Quick questions

[Sean Middleditch]

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 actually sat down to start prototyping my first D-BUS service and
client library today and was pretty much halted solid from the state of
the documentation; the tutorial is useless and the API reference really
isn't something you can learn off of.

Right now the justification/explanation for all this can only really be
found by digging through the dbus archives which is a pain.

> 
> 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?  What form should the object path take - domain-based
like /org/service/object or just generic like /object ?  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?  Why is the object mandated
to be in path-form instead of something app/service defined?

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

> 
> 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" ?   Are interfaces attached to the object/path or the service?
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?  Any real life examples of where interfaces are
needed/useful?

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.

> 
> The method name is just like a method name in a programming language.

-------------- 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/xdg/attachments/20050114/ffd9ca9a/attachment.bin