Proposal and RFC: DAL, the Desktop Abstraction Layer

[Havoc Pennington]

On Sat, 2005-01-15 at 12:08 +0000, Jamie McCracken wrote:
> > 
> > e.g. if you have the name org.freedesktop.TextEditor you have to have
> > object /org/freedesktop/TextEditorApplication that implements X,Y,Z.
> 
> But the service names are unique so what happens if you have gedit and 
> kwrite - they cant both be called org.freedesktop.TextEditor. So would 
> gedit be /org/gnome/gedit then? If so how will I know it has a certain 
> interface without *knowing* about the app?

You can call Introspect() to learn about all objects and interfaces in
the app.

> To me service name is just an alias to the executable name, interface is 
> well an interface (a well defined one perhaps) - Im not confused by that 
> but I must admit it could be clearer in the documentation.

OK, for the last time: I don't need advice on the documentation! I know
the documentation isn't finished, because there are *specific*
longstanding plans for when to complete specific parts of the docs based
on intended changes to the code itself. I'm not going to document
something that I know full well is going to be different in 1.0.
*After* 1.0, I'll take comments on the docs...

> > If we have activation via interface, then probably you don't want to
> > have service names at all - after all, do you activate the
> > org.freedesktop.TextEditor service, or do you query for implementors of
> > org.freedesktop.TextEditor interface and activate one of those?
> > I think it's really confusing to have both options available.
> 
> Well you need them in differernt circumstances. If you want to 
> communicate with a certain app then yes service name is all you need but 
> in my email client example where I want to remote control any compliant 
> email client that becomes impossible without the ability to query 
> services for interfaces.

There is introspection already.

> > The reason interfaces are separate from service names right now is that
> > interfaces are on objects and names are names of applications. So one
> > app can have 3 objects that implement org.freedesktop.TextDocument, for
> > example.
> 
> The problem there is one must have a priori knowledge of what the 
> services are called. Its rather limited if an app I write today cant 
> make use of new services defined in some future app or if I'm ignorant 
> of other available apps.

How are you going to use new interfaces not known at the time of writing
your app?

This is all totally hypothetical stuff. I'm not saying we'll never add
any of this, but I'm definitely not going to add it until we get some
experience with the basics.

> > Which is the other issue with activation-by-interface: the *app* doesn't
> > implement interfaces, objects inside the app do. So if you query for
> > whether the app implements org.freedesktop.TextDocument, what does that
> > mean? In principle the app doesn't have to have a document open even.
> 
> yes but there should be sufficient functionality in the interfaces to 
> get that state of an app. In MS office apps you can query whether a doc 
> is open or not so thats more a question for the specs for an app's 
> interfaces rather than Dbus.

You don't understand. The proposal to query 'what interfaces a service
implements' doesn't make sense because apps don't implement interfaces;
object instances do.

That's why we have a method Introspect() that returns the interfaces
*for an object instance*

But you can't activate a service based on this because it doesn't make
any sense to ask which apps implement an interface. That's like saying,
which apps implement java.lang.Cloneable. It's just not useful
information.

We could ask which apps could own the name org.freedesktop.TextEditor,
for example. That is useful information.

Havoc