Proposal and RFC: DAL, the Desktop Abstraction Layer

[Havoc Pennington]

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