Proposal and RFC: DAL, the Desktop Abstraction Layer
Havoc Pennington
hp@redhat.com
Fri Jan 14 17:39:08 PST 2005
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.
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.
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.
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.
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.
> 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.
Havoc
More information about the dbus
mailing list