linuxaudio.org

--0016e6de006aa327a204c0a4beba

Content-Type: text/plain; charset=ISO-8859-1
On Tue, May 22, 2012 at 7:35 PM, Nikita Zlobin  wrote:
> Hi all. Just returned from military services (mandatory period).

quoted text
> It is likely, that i was somehow unsubscribed from list.

>

> In summary, proposed changes are joined in two parts:

> 1. A few advances for freewheel mode: waiting wheel and per client

> free/waiting wheel mode.

> 2. Get support for any count of "rooms", as they are called in LADISH

> therminology, but IMHO, a bit more flexible.

>

I'm sorry but I don't agree with any of these ideas.
One of the guiding design philosophies behind JACK's design has been to

avoid trying to create an API that covers every possible use case,

including all the obscure ones. We have seen several examples of this (the

most notable being SGI's graphics API) which provide the general lesson

that adding complexity in order to be able to satisfy the least common 10%

of use cases invariably causes unnecessary complexity for the common 80%.
If you want a "room" like concept then please work on providing per-port

metadata (I can post a header that describes a proposed API), because I

believe that this will provide everything necessary to do this without

JACK's involvement. This is an important addition to the API, and will

facilitate many things that are useful and moderately common.
--0016e6de006aa327a204c0a4beba

Content-Type: text/html; charset=ISO-8859-1

Content-Transfer-Encoding: quoted-printable
On Tue, May 22, 2012 at 7:35 PM, Nikita =

Zlobin <cook60020tmp@mail.ru> wrote:

Hi all. Just returned from military services (mandatory period).

It is likely, that i was somehow unsubscribed from list.
In summary, proposed changes are joined in two parts:

1. A few advances for freewheel mode: waiting wheel and per client

free/waiting wheel mode.

2. Get support for any count of "rooms", as they are called in LA=

DISH

therminology, but IMHO, a bit more flexible.I&#39=

;m sorry but I don't agree with any of these ideas. One of the =

guiding design philosophies behind JACK's design has been to avoid tryi=

ng to create an API that covers every possible use case, including all the =

obscure ones. We have seen several examples of this (the most notable being=

 SGI's graphics API) which provide the general lesson that adding compl=

exity in order to be able to satisfy the least common 10% of use cases inva=

riably causes unnecessary complexity for the common 80%.

If you want a "room" like concept then please work on providi=

ng per-port metadata (I can post a header that describes a proposed API), b=

ecause I believe that this will provide everything necessary to do this wit=

hout JACK's involvement. This is an important addition to the API, and =

will facilitate many things that are useful and moderately common. 
--0016e6de006aa327a204c0a4beba--