Common Desktop Interface Specification (aka CDIS), initial work

Ikke eikke at eikke.com
Sun Jan 23 12:51:25 EET 2005


> I think you need to go back and update your original DAL proposal, to create a 
> coherent vision (problem statement, architecture, technologies, etc).
I will do this first, you're right.
> I don't have enough cross-desktop experience to tell whether the auto-translation is 
> going to work in general, but it is certainly a fine goal.
It should be possible :) I've got some experience with this using PHP
(LDAP schema to PHP class file), so this one should be possible to do
too :)

> As part of your specification design, you should probably review the methods 
> that are exported from various applications that already exist. In 
> particular, what you are designing is obviously pretty close to the way KDE 
> apps provide dcop interfaces. So it might be worth looking at what Juk (for 
> example) provides, and the types it returns.
As I tried to explain, this is no attempt at creating real interface
descriptions, rather creating the description format. The question is:
are Events with arguments, and Methods with Arguments and ReturnValues
sufficient, and are all necessary fields for all transmitted values
described in the format?

> It might also be worth trying to figure out how you support optional features 
> - which might be what a previous poster referred to as "profiles".
> For example, if the music player support the concept of a collection or playlist, 
> do you want to be able to get the name of the current collection or playlist, 
> or to change it. Now, if that is a required feature, then music players that 
> don't provide it can't implement the spec (even though they might be able to 
> do the main job - play a music track). If that isn't available, you are 
> loosing functionality in your interface, and people will bypass it and go 
> back to the per-application interface design, without CDIS.
True. Which means I should add some sort of "inheritance" of interfaces
(PlaylistMusicPlayer inherits MusicPlayer in your example, although I
don't like that name ;))
CDIS should provide very common interfaces (and I agree, Playlists are a
common thing). Very specialised features only implemented by one
application or so should not get into a CDIS interface. CDIS does not
prohibit specialized/non-standard inter-application communication. It
should only provide the capabilities to do "common" communictation,
shared amongst almost all application providing a certain service. An
application can provide 2 things: it can implement a CDIS interface (and
so it should), and next to this it can offer some extra features, which
will only be used by other apps suited for this features.

> Brad

Ikke



More information about the xdg mailing list