Thiago,<br><br><div><span class="gmail_quote">On 1/9/07, <b class="gmail_sendername">Thiago Macieira</b> &lt;<a href="mailto:thiago@kde.org">thiago@kde.org</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>An out-of-process implementation of a few D-Bus API calls would be almost<br>trivial to implement in a running daemon that desktop environments<br>already provide. They already have theming capabilities -- or will<br>
have -- and already have all the necessary resources to play sound<br>already.</blockquote><div><br>That would mean it explicitly force programs to use dbus &amp; a sound server to play a sound. That sound a bit too much for me. We have mixing capabilities in hw, or even in-process with dmix. Why should we &quot;force&quot; such a simple library to depend on dbus a seperate process? As far as I know, e17 does not depend on it (or at least, it seems you can disable it). Neither do Firefox and people that simply use ion &amp; vim on a limited terminal. I don&#39;t like the idea to push dbus for something like playing simple sound events. Notifications frameworks, for example, can justify the dependency on DBus. But sound_play(&quot;bling&quot;) &quot;dependent&quot; on DBus looks a bit too much to convince me... I would probably stick to an SDL_Mixer, or a PortAudio API to play a &quot;bling&quot; in this case, if I need to write a small, static program for an embedded use, for example.
<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">And you could add the sound calls to DAPI. No need for an *extra* library<br>(each .so is an added cost on program load time). Especially if your
<br>library would require loading of libogg, libvorbis and libalsa -- that&#39;s<br>four DSO that would be loaded.</blockquote><div><br>That would be loaded by an external process: libraries need to be loaded anyway. Why people are more confident on system capabilities with IPC and multiple process than on simple memory sharing (if we expect the code to be runtime error clean)? I sometime wonder.
<br><br>If I was not clear enough, this DS API has *also* the goal to define DBus interfaces for fd.o. (btw this is just a C API, it can be quite easily rewritten to any language, I seriously think). <br><br>Best regards,
<br></div><br></div><br>-- <br>Marc-André Lureau, GSmartMix