Hi there,<br><br>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.<br><br>Discussions on xdg. Thiago proposed that such interface could be added to DAPI.<br><a href="http://lists.freedesktop.org/archives/xdg/2007-January/008995.html" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://lists.freedesktop.org/archives/xdg/2007-January/008995.html
</a><br><br>The interface proposal is here, providing C headers (with async handling) and D-Bus spec.<br clear="all"><a href="http://etudiant.epita.fr/%7Elureau_m/ds-0.1/" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://etudiant.epita.fr/~lureau_m/ds-0.1/</a><br><br>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.
<br><br>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.
<br><br>I would rather have that in mind:<br><br>DAPI/<br> data/<br> dapi-dbus.xml<br> ...<br> include/ (similar to the dapi-sound.h file I propose)<br> dapi.h<br>
dapi-sound.h<br> dapi-whatever.h<br> src/ <br> common/<br> -> libcommon{a,so,h}<br> utils.{h,c}...<br><br> os/ if necessary (see portaudio dir structure)
<br> -> libos{a,so,h}<br> osx.h<br> freebsd.h<br><br> libsound/ (differents backends)<br> -> libsound{a,so,h}<br>
pulse/<br>
gstreamer/<br>
phonon/<br> dbus/<br> implement dapi-sound dbus api (can use any dbus daemon this way)<br><br> client/ (different flavours for each desktop)
<br> -> libdapi.{a,so,h}<br> dbus/<br> use all the generic dbus calls (no other dependency than dbus for the client)<br> gnome/<br>
specific gnome impl. (can avoid D-Bus, and use../../audio/pulse or ../../audio/gstreamer (ISV choice)<br> kde/<br> specific kde impl. (...) using ../audio/phonon or a part of ../dbus/
<br> daemon/ (different flavours of daemons, compatible design choice with the corresponding libclient)<br> -> dapi-daemon<br> dbus/<br> should implement all the DBus specs.
<br> gnome/<br> can use ../../audio/pulse result and avoid implementing all the DBus specs. <br> kde/ <br> can use ../../audio/phonon result
<br><br>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:)<br><br>PS: switch to git and Doxygen while it is still time!
<br><br>-- <br>Marc-André Lureau, GSmartMix