Common Desktop Interface Specification (aka CDIS), initial work
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
> 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.
More information about the xdg