[Portland] DAPI Sound for Portland? and general comments

[Marc-André Lureau]

Hi there,

Recently, I have been working on a desktop sound interface. I hope that
such, relatively simple, work can be shared. I don't worry about backends
and implementation details when I just want to do simple things. There seems
to be no such  clear API available. Or in the contrary, there is too much
choice, and nobody really know what would be the best. Instead, let's talk
of common features and things we would like to see coming soon, like theming
and simple, nice properties (capabilities can be limited by implementation).
That way, I would say DAPI  has the very same ambition.

Discussions on xdg. Thiago proposed that such interface could be added to
DAPI.
http://lists.freedesktop.org/archives/xdg/2007-January/008995.html

The interface proposal is here, providing C headers (with async handling)
and D-Bus spec.
http://etudiant.epita.fr/~lureau_m/ds-0.1/<http://etudiant.epita.fr/%7Elureau_m/ds-0.1/>

Regarding DAPI "core", what about a common vtable for main loops/events,
similar to the one of D-Bus (instead of just leaving fd to watch for)? It is
interesting for different services implementation without big limitations, I
guess.

And what else? What is the current state of DAPI? It seems that the Gnome
DBus daemon is ok, but I don't see a wrapper for a common C API (that would
hide the fact that there is a DBus IPC). For me, it looks close to my
initial design plan, but the CVS structure does not cleanly express so.

I would rather have that in mind:

DAPI/
        data/
                dapi-dbus.xml
                ...
        include/ (similar to the dapi-sound.h file I propose)
                dapi.h
                dapi-sound.h
                dapi-whatever.h
        src/
                common/
                     -> libcommon{a,so,h}
                     utils.{h,c}...

                os/ if necessary (see portaudio dir structure)
                     -> libos{a,so,h}
                     osx.h
                     freebsd.h

                libsound/ (differents backends)
                     -> libsound{a,so,h}
                     pulse/
                     gstreamer/
                     phonon/
                     dbus/
                             implement dapi-sound dbus api (can use any dbus
daemon this way)

                client/ (different flavours for each desktop)
                     -> libdapi.{a,so,h}
                     dbus/
                             use all the generic dbus calls (no other
dependency than dbus for the client)
                     gnome/
                             specific gnome impl. (can avoid D-Bus, and
use../../audio/pulse or ../../audio/gstreamer (ISV choice)
                     kde/
                             specific kde impl. (...) using ../audio/phonon
or a part of ../dbus/
                daemon/ (different flavours of daemons, compatible design
choice with the corresponding libclient)
                     -> dapi-daemon
                     dbus/
                             should implement all the DBus specs.
                     gnome/
                             can use ../../audio/pulse result and avoid
implementing all the DBus specs.
                     kde/
                             can use ../../audio/phonon result

Would it be cleaner/generic? I know, that's a lot of work and ideas. But
that does not seem impossible. That will be extensible. Just tell me if I am
silly! I won't get surprised:)

PS: switch to git and Doxygen while it is still time!

-- 
Marc-André Lureau, GSmartMix
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/portland/attachments/20070110/16d4d8db/attachment.htm