<br><br><div class="gmail_quote">On Wed, May 23, 2012 at 3:30 PM, Nikita Zlobin <span dir="ltr"><<a href="mailto:cook60020tmp@mail.ru" target="_blank">cook60020tmp@mail.ru</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
What things, you think, may need to create such all-purpose API?</blockquote><div><br>What is the use case for "Per client time wheel management." ?<br>What is the use case for "Waiting wheel. ?"<br><br>
Unless these represent common uses of JACK, the required features have no role in the API. Currently, these look like corner cases to me.<br><br>It it true that I skipped over the proposal for dynamic/on-the-fly backend switching. This has already been discussed and yes, it would be great to add it. Torben did this for his "tschak" implementation. Its another example of something that needs to be done, not discussed.<br>
 </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> As for<br>
rooms - it is just a side effect of what i propose. JACK api doesn't<br>
need to be changed; way to select jack instance by client may be same<br>
as today. I'm not sure even, that you read message up to end -<br>
including proposed structure.<br></blockquote><div><br>I did read it to the end, which is why I remarked on the port metadata idea which would make the "rooms" idea much easier to implement and manage efficiently.<br>
<br> </div></div><br>