Proposal and RFC: DAL, the Desktop Abstraction Layer

[Ikke]

> Dont forget versioning too - what 
> happens if your standard services spec changes? How will I know which 
> version they support? etc - sounds like DLL hell to me!

As long as you hide the specification and communication-implementation
(DBUS) details after some strict API/library, the client apps that use
your spec will never need to know the specification version changed.

If I got version A of the spec, which says I should provide a method
getEmailDetails(emailid) which returns a "struct" likte this:

	String mailSender;
	String mailSubject;

Now in my abstraction lib, I got a function like this:
getEmailDetails(emailid, DAL_EMAIL_SUBJECT), which returns mailSubject.

If we change the spec (e.g. we dont like the name mailSubject, because
we always know the Subject is the subject of an email) and want
getEmailDetails(id) to return this:
	String Sender;
	String Subject;
	int numberOfAttachments;
(so we also add some information, this is just a sample). Now we change
the client library, make sure getEmailDetails(id, DAL_EMAIL_DUBJECT)
returns 'Subject' now instead of 'mailSubject'. The client app won't
ever notice this.

On the sender side, same thing: it's the lib that takes care of labeling
the returned information properly.

This way we can add/rename properties easily while still being backwards
compatible.

Of course when big changes happen we can still fall back on version
numbers of the standard (DAL v1.0, DAL v2.0,...) :-)


Maybe this explanation sounds a bit strange, its not easy to explain for
me though.

Regards,

Ikke