On Thu, 28.05.09 09:38, Colin Guthrie (gmane at colin.guthr.ie) wrote: > > 'Twas brillig, and Patrick Shirkey at 28/05/09 06:31 did gyre and gimble: >> Thanks for the heads up. There is no desire to use an api that is not >> going to be future proofed. Would you consider having a "pajackcontrol" >> app that uses dbus to communicate with pa and provides the existing api >> hooks to jack so that legacy jack and non dbus jack can still signal pa >> to play nicely? > > Providing backwards compatibility is one thing but if the pulse client > library just decides to use DBUS rather than sockets, why should any > client application care? I don't think there is any intended client API > breakage. That wouldn't go down well! Actually, if we adopt RTP for data transfer we'll probably do that in a way that is incompatible with the current API. One of the weaknesses of the current protocol is that we shove control and audio data over the same channel. When we go for RTP we will will have seperate, independant channels for each stream of audio data. When we have that we will probably not be able to make the same ordering guarantees of the client requests we currently make. But uh. The whole RTP+D-Bus story is nothing I'll be working on any time soon. I'd rather not talk too much about it right now. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4
