Proposal and RFC: DAL, the Desktop Abstraction Layer

[Jamie McCracken]

Havoc Pennington wrote:
> On Fri, 2005-01-14 at 14:44 +0000, Jamie McCracken wrote:
> 
>>Looking at the API, I cant see a function that retrieves a list of 
>>services that implement an interface.
> 
> 
> The assumption so far is that well-known service names will be a
> contract that you provide particular objects that implement particular
> interfaces.
> 
> 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?


> if you also have the name org.freedesktop.TextEditor2 you implement some
> additional stuff perhaps.
> 
> People are already pretty confused about the whole service names vs.
> interfaces vs. object paths issue, if we say activation can be via name
> *or* interface that seems to be even more confusing to me. 

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.

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

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

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


> 
> 
>>As I have also stated in my other emails the interface is just a string 
>>and doesn't represent versioning of that interface. Wont that be a 
>>potential problem in the future?
> 
> 
> To version things, just add a version number to the name of the
> interface. If we added version numbers we'd just use the name + version
> pair to identify the interface, rather than the name alone. But
> separating them just gives us room to screw this up.

Okay thats fine.

jamie.
> 
> Havoc
> 
> 
> 
>