Proposal and RFC: DAL, the Desktop Abstraction Layer
Havoc Pennington
hp@redhat.com
Fri Jan 14 17:27:35 PST 2005
On Fri, 2005-01-14 at 11:37 +0000, Jamie McCracken wrote:
> <profile ID="1345">
> <name>email profile</name>
> <version>1</version>
> <methods>
> <method name="SendMail">declare params here etc</method>
> <method name="NewMail">declare params here etc</method>
> </methods>
> <events>
> <event name="OnMailReceive"/>
> <event name="OnMailSent"/>
> </events>
> </profile>
That looks like an interface to me...
I guess we could have a higher-level concept of "has interfaces A,B,C
and objects X,Y,Z" but I'm not convinced a priori we need to have a
formal way to check for that. I would suggest we wait and get some real-
world experience and then we'd know how to add it.
Versioning of interfaces is pretty simple: once something is published
you can't change it without renaming it. Well, for D-BUS we can probably
be more liberal and say you can't remove or change methods; adding
methods/fragile-base-class should be irrelevant in a D-BUS context.
I've absently thought about a couple ideas to make all this cleaner:
- some way to mark interfaces as published/unpublished and throw
an error if third party apps look at unpublished; but I can't figure
out how to define "third party" or detect it
- have some sort of fast way to check whether an interface is
implemented, other than asking for and verifying the full
introspection data; you can imagine e.g. just a hash of the
interface. But there are problems e.g. if you add to the
interface, and I'm not sure this is worth extra complexity
All of these things can really be added post-1.0 and after we get some
real-world experience so I'm not going to rush and put them in. They can
also be prototyped in a "binding" context rather than D-BUS core.
Havoc
More information about the dbus
mailing list