[proposal] connection veto callback

[torbenh]

nedko and me came to the conclusion, that there are several reasons, why
applications should be forbidden to make some connections.

- lash session loading.
- connection ACLs
- application is dumb.

in order to not clutter jack code, with several ideas of how to
configure ACL or whatever, the solution seems to b a callback
clients can register.

bool
veto_connection( char *client_requesting_connection, char *src_port, char *dst_port )

control apps can register, and before actual connection is made, the
callbacks are executed in the control apps which register.

results are ORed and if its TRUE, then the connection is NOT made.
i prefer the result of jack_connect to be SUCESS in this case, because
dumb apps just close their jack client in case of connect failure.

but this is easy to make configureable. i would like to not have an enum
in the signature of the callback, because it makes the semantics much
more complex. iE one control app says FAIL, the other says
DONT_CONNECT_BUT_SUCCED... what to tell the app now ?

of course care must be taken, about timeouts and stuff. but i think we
have code for this already.


--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Nedko Arnaudov]

torbenh@... writes:

> nedko and me came to the conclusion, that there are several reasons, why
> applications should be forbidden to make some connections.
>
> - lash session loading.
> - connection ACLs
> - application is dumb.
>
> in order to not clutter jack code, with several ideas of how to
> configure ACL or whatever, the solution seems to b a callback
> clients can register.
>
> bool
> veto_connection( char *client_requesting_connection, char *src_port, char *dst_port )
>
> control apps can register, and before actual connection is made, the
> callbacks are executed in the control apps which register.
>
> results are ORed and if its TRUE, then the connection is NOT made.
> i prefer the result of jack_connect to be SUCESS in this case, because
> dumb apps just close their jack client in case of connect failure.
>
> but this is easy to make configureable. i would like to not have an enum
> in the signature of the callback, because it makes the semantics much
> more complex. iE one control app says FAIL, the other says
> DONT_CONNECT_BUT_SUCCED... what to tell the app now ?
>
> of course care must be taken, about timeouts and stuff. but i think we
> have code for this already.

Disconnect veto is needed too.

Isn't single vetoer enough to solve current problems? If so, we can
avoid overeneneering and make veto_connection callback registration
succeed only once. I think the window manager approach in X11 is good
enough. User chooses one patchbay supervisor (vetoer) and expects
it to fulfil all his needs. At very minimum we should make single vetoer
default behaviour and provide an option to jack server that enables
multiple vetoers.

We need veto callback unregistration too.

--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>


_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Paul Davis]

On Thu, May 28, 2009 at 3:09 AM, Nedko Arnaudov <nedko@...> wrote:
> torbenh@... writes:
>
>
> We need veto callback unregistration too.

jack_set_connection_veto_callback (jack_client, NULL, NULL);

??
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Nedko Arnaudov]

Paul Davis <paul@...> writes:

> On Thu, May 28, 2009 at 3:09 AM, Nedko Arnaudov <nedko@...> wrote:
>> torbenh@... writes:
>>
>>
>> We need veto callback unregistration too.
>
> jack_set_connection_veto_callback (jack_client, NULL, NULL);
>
> ??

patchbay supervisor may need to know what connection is being
disconnected. For example it *may* want to restrict connections to other
clients only because it assumes that connections between ports of a
client are part of client internal state.

--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>


_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Fons Adriaensen-2]

On Thu, May 28, 2009 at 08:23:06AM +0200, torbenh@... wrote:

> nedko and me came to the conclusion, that there are several reasons, why
> applications should be forbidden to make some connections.
>
> - lash session loading.
> - connection ACLs
> - application is dumb.
>
> in order to not clutter jack code, with several ideas of how to
> configure ACL or whatever, the solution seems to b a callback
> clients can register.

> bool
> veto_connection( char *client_requesting_connection, char *src_port, char *dst_port )

As one who had to pay 800 Euro last year to repair the damage
done by one famous app that connected where it shouldn't have
(this money could have gone to its developers but didn't) I'm
all pro some form of access restrictions on ports.

But IHMO this veto system has all it takes to create more
miseray than it could solve - it basically allows any app
to veto any connection, making it impossible to decide or
configure this on any higher level. One would need a veto
system agains clients abusing this to ensure things remain
sane.

If clients want to restrict access to their own ports that
is OK. Anything else should not be the business of any
particular client but be decided higher up.

Ciao,

--
FA

Io lo dico sempre: l'Italia è troppo stretta e lunga.

_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Glynn Clements]

Nedko Arnaudov wrote:

> Disconnect veto is needed too.

> We need veto callback unregistration too.

I'm not sure how useful this would be; you can't veto a client
exit()ing.

> Isn't single vetoer enough to solve current problems? If so, we can
> avoid overeneneering and make veto_connection callback registration
> succeed only once. I think the window manager approach in X11 is good
> enough. User chooses one patchbay supervisor (vetoer) and expects
> it to fulfil all his needs. At very minimum we should make single vetoer
> default behaviour and provide an option to jack server that enables
> multiple vetoers.

FWIW, I agree that X window managers are the appropriate model.

One client gets to be the final arbiter of all connections. If a
supervisor exists, any connection attempt becomes a request which is
reported to the supervisor.

The supervisor may make the requested connection, reject the request,
or make the connection to an alternative port (redirection).

Redirection would allow a "dumb" client which automatically connects
to the first two hardware ports to be connected at a more appropriate
point in the graph, and to allow redirection to "null" ports if you
don't want to allow the client to participate but don't want it to
quit due to an error (e.g. playing a video when you don't need the
sound).

--
Glynn Clements <glynn@...>
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Nedko Arnaudov]

Glynn Clements <glynn@...> writes:

> Nedko Arnaudov wrote:
>
>> Disconnect veto is needed too.
>
>> We need veto callback unregistration too.
>
> I'm not sure how useful this would be; you can't veto a client
> exit()ing.

It is useful when bisbehaving client disconnects ports that are
connected by LASH during session load.

> FWIW, I agree that X window managers are the appropriate model.
>
> One client gets to be the final arbiter of all connections. If a
> supervisor exists, any connection attempt becomes a request which is
> reported to the supervisor.
>
> The supervisor may make the requested connection, reject the request,
> or make the connection to an alternative port (redirection).
>
> Redirection would allow a "dumb" client which automatically connects
> to the first two hardware ports to be connected at a more appropriate
> point in the graph, and to allow redirection to "null" ports if you
> don't want to allow the client to participate but don't want it to
> quit due to an error (e.g. playing a video when you don't need the
> sound).

Yup. :D

--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>


_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[torbenh]

On Thu, May 28, 2009 at 10:00:46PM +0200, Fons Adriaensen wrote:

> On Thu, May 28, 2009 at 08:23:06AM +0200, torbenh@... wrote:
>
> > nedko and me came to the conclusion, that there are several reasons, why
> > applications should be forbidden to make some connections.
> >
> > - lash session loading.
> > - connection ACLs
> > - application is dumb.
> >
> > in order to not clutter jack code, with several ideas of how to
> > configure ACL or whatever, the solution seems to b a callback
> > clients can register.
>
> > bool
> > veto_connection( char *client_requesting_connection, char *src_port, char *dst_port )
>
> As one who had to pay 800 Euro last year to repair the damage
> done by one famous app that connected where it shouldn't have
> (this money could have gone to its developers but didn't) I'm
> all pro some form of access restrictions on ports.
>
> But IHMO this veto system has all it takes to create more
> miseray than it could solve - it basically allows any app
> to veto any connection, making it impossible to decide or
> configure this on any higher level. One would need a veto
> system agains clients abusing this to ensure things remain
> sane.
>
> If clients want to restrict access to their own ports that
> is OK. Anything else should not be the business of any
> particular client but be decided higher up.

actually this is what i am fearing a bit too. iE dumb client vetoing
disconnect of their autoconnected ports.

*shiver*

i actually dont expect anybody to be this dumb. but we cant rely on it.
the problem is that i have identified at least 2 clients (which may run
simultaneously) who could take advantage of this feature.

however all clients identified yet, dont have own ports. maybe it would
make sense to exclude clients which own ports from this system ?


--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Fons Adriaensen-2]

On Sat, May 30, 2009 at 12:15:57PM +0200, torbenh@... wrote:

> On Thu, May 28, 2009 at 10:00:46PM +0200, Fons Adriaensen wrote:

> > But IHMO this veto system has all it takes to create more
> > miseray than it could solve - it basically allows any app
> > to veto any connection, making it impossible to decide or
> > configure this on any higher level. One would need a veto
> > system agains clients abusing this to ensure things remain
> > sane.
> >
> > If clients want to restrict access to their own ports that
> > is OK. Anything else should not be the business of any
> > particular client but be decided higher up.
>
> actually this is what i am fearing a bit too. iE dumb client vetoing
> disconnect of their autoconnected ports.
>
> *shiver*

*Shiver* indeed. And I wouldn't be surprised at all
if some apps start doing this sort of thing.

I've been musing a lot about this and related issues
lately. There's yet no complete picture resulting from
this, but some ideas seem to emerge and wanting to stay.

One of them is this: allowing any jack client to make its
own connections (or others) is seen as a 'natural' thing
because this is, and always has been, part of the client
API. But is it such a good idea ? I'm more and more
convinced it isn't.

It certainly does not correspond to anything in the
'real' (hardware) world. Pieces of audio equipment
do not connect themselves.

One step beyond this is 'persistent application ports'
- these correspond to an application but exist even
if the application doesn't run. Instead of creating
them the app would 'bind' to them. Once the app runs
the net result is the same as it is now. But since
these ports can be semi-permanent (in the sense that
they are created as part of a more or less fixed
studio setup) their connections can be as well.

Again this corresponds more to a hardware scenario:
when you install a new piece of equipment it gets
a place in a rack and is wired to the patchbay.
The patchbay sockets are permanent, they exist
even if the equipment is not used or switched off.

It is this permanent wiring to a central patching
device that allows you to set up a studio once and
then use it a hundred times by just switching it
on. What we do now in software corresponds more to
breaking down your studio completely after each
session, and having to rewire it from scratch for
the next. The applies to jack, to ardour sessions,
and also to what LASH tries to do.

One more: in a 'real' studio having a hardware
mixer (or even a control surface looking like
a real mixer), it is the mostly the mixer that
is used for routing signals. Suppose someone
walks in with his MP3 player and saying 'you
should listen to this'. Will you wire the player
to the monitoring amps ? Probably not. You plug
it into two free mixer line inputs on the patchbay
and use the mixer to determine how to listen to
it.

What allows you to do this is that the mixer is
there all the time, its structure is more or less
fixed, and many if its inputs and outputs are wired
semi-permanently - even if not used - in a way that
makes practical sense. All you need to do is push
up a fader and hit a button or two. Even recalling
a session and restoring a complete mixer state does
not modify it in an essential way. And it certainly
does not modify the external wiring. It may change
the way connectors map to internal signals, but
that is something quite different - and internal.

--
FA

Io lo dico sempre: l'Italia è troppo stretta e lunga.

_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Bob Ham]

On Sat, 2009-05-30 at 23:11 +0200, Fons Adriaensen wrote:
> allowing any jack client to make its
> own connections (or others) is seen as a 'natural' thing
> because this is, and always has been, part of the client
> API. But is it such a good idea ? I'm more and more
> convinced it isn't.

I'd agree with you; LASH would be a lot simpler if JACK clients weren't
able to connect their own ports.  However, LASH is also a JACK client.
At some point, there has to be some API for external applications to
connect JACK ports together.  Otherwise, relying on static configuration
of ports would reduce the flexibility of JACK, and its power.  And
moving the API out of libjack would only obfuscate it, not remove the
capability.

There is also the issue of the valid use of JACK ports to connect audio
objects within a single client, such as ardour.  Such clients would all
need to reimplement the currently-shared port connection functionality
that already exists within JACK and this doesn't seem like a good idea.


> It certainly does not correspond to anything in the
> 'real' (hardware) world. Pieces of audio equipment
> do not connect themselves.

I agree with this; I really dislike the ubiquitous "auto-connect output
ports to hardware ports" functionality.  IMHO this is the job of a
session manager or some other layer outside the client.

You could modify the semantics of the existing JACK API to only allow
connections to and from a client's own ports.  But then, again in order
to support inter-client connections, there will need to be another API
that will allow this.  And then the "we'll do everything for you"
clients (rosegarden, ardour, etc, etc) will just take to using the
separate API.  To do everything for you :-)

Possibly the veto is the way to go.  In fact, you could implement any
restriction scheme you liked using a veto.  The key issue is that there
must be no way to veto the veto, otherwise you're back at square one.


> One step beyond this is 'persistent application ports'
> - these correspond to an application but exist even
> if the application doesn't run. Instead of creating
> them the app would 'bind' to them.

> Again this corresponds more to a hardware scenario:
> when you install a new piece of equipment it gets
> a place in a rack and is wired to the patchbay.

> What we do now in software corresponds more to
> breaking down your studio completely after each
> session, and having to rewire it from scratch for
> the next. The applies to jack, to ardour sessions,
> and also to what LASH tries to do.

This does seem like a good idea.  Really, though, it's just a matter of
what software does it.  Some software at some point will have to
construct this static patch bay from some configuration file.

At present, this is the kind of functionality that LASH aims to support.
The 'binding' occurs through the creation of consistently named ports,
which LASH will then connect appropriately according to the
configuration stored in the session.  LASH could also refer to a static
map in addition to the session configuration; that wouldn't be much of a
change.  The details of specifying and matching against a static map
would probably be non-trivial, though.

Bob

--
Bob Ham <rah@...>


_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Glynn Clements]

Fons Adriaensen wrote:

> Again this corresponds more to a hardware scenario:
> when you install a new piece of equipment it gets
> a place in a rack and is wired to the patchbay.
> The patchbay sockets are permanent, they exist
> even if the equipment is not used or switched off.
>
> It is this permanent wiring to a central patching
> device that allows you to set up a studio once and
> then use it a hundred times by just switching it
> on. What we do now in software corresponds more to
> breaking down your studio completely after each
> session, and having to rewire it from scratch for
> the next. The applies to jack, to ardour sessions,
> and also to what LASH tries to do.

Some of this is inevitable for a "virtual" studio.

The "hardware" (client processes) vanishes whenever the user logs out.
It may not rematerialise upon the next login (e.g. the program may
have been uninstalled). And if you have more than one instance of a
program (two seemingly identical pieces of hardware), how do you
decide which one is which?

With a physical studio, persistence of hardware and connections is
inherent. With a virtual studio, persistence must be *made* to happen.

--
Glynn Clements <glynn@...>
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Fons Adriaensen-2]

On Sun, May 31, 2009 at 12:28:06AM +0100, Bob Ham wrote:

> Possibly the veto is the way to go.  In fact, you could implement any
> restriction scheme you liked using a veto.  The key issue is that there
> must be no way to veto the veto, otherwise you're back at square one.

It again is a distributed thing rather than centralised,
so while consistent with the current situation is goes
the wrong way. And it is *much* too easy to abuse, e.g
clients blocking removal of their self-made connections.
 
> At present, this is the kind of functionality that LASH aims to support.
> The 'binding' occurs through the creation of consistently named ports,
> which LASH will then connect appropriately according to the
> configuration stored in the session.

It is also what the Qjackctl patchbay supports partially.
When the ports re-appear, it remakes the connection.
The difference to really persistent ports is that in
Qjackctl an app's ports are invisible while the app
doesn't run. If Qjackctl would also display all ports
in a patchbay allow you to modfy their connections in
the normal connection dialog, it would be a near perfect
emulation of 'persistent ports'. But such a thing is much
more easy to write if ports are _really_ persistent in the
server.

Another part missing from any emulation that LASH or
Qjackctl would be able to offer if this: to work well
such persistent ports need _two_ names. One on the
client side, which the client uses to refer to its
ports for 'binding' to them, and which never change.
The second is the name used externally (the label in
a GUI), which can change at any time.

For example mixer app could have fixed ports identifiers
such "myname:ch-1", "myname:ch-2", etc. while it could
e.g. use track names to label ports for the external
world (and on its own GUI). Any storage of the fixed
connections must be based on the fixed names only, why
the variable ones are for interactive (human) use.

Ciao,

--
FA

Io lo dico sempre: l'Italia è troppo stretta e lunga.

_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Bob Ham]

On Sun, 2009-05-31 at 11:11 +0200, Fons Adriaensen wrote:

> On Sun, May 31, 2009 at 12:28:06AM +0100, Bob Ham wrote:
>
> > Possibly the veto is the way to go.  In fact, you could implement any
> > restriction scheme you liked using a veto.  The key issue is that there
> > must be no way to veto the veto, otherwise you're back at square one.
>
> It again is a distributed thing rather than centralised,
> so while consistent with the current situation is goes
> the wrong way. And it is *much* too easy to abuse, e.g
> clients blocking removal of their self-made connections.

Well, really this can already be done; clients can register port
connection callbacks and monitor their own ports, reconnecting them if
they're disconnected.  As far as I know, this hasn't been done.  Which
isn't surprising as it kind of undermines one of main objectives of
taking part in a JACK graph: the flexibility.

I don't really see it as an issue of "abuse"; client authors are free to
write whatever software they wish, and people are free to use or not use
that software.  If we provide the facility for a port-connection veto,
people will make use of that.  They may produce systems that work for
themselves but not for others.  They may produce systems that work for
everybody.

I don't see this as a problem; the risk of some functionality
facilitating systems that only work for some people isn't a risk in my
eyes; nothing is lost.

Having said that, I am curious as to what software would make use of a
veto.  Torben, you mentioned you had identified two clients; which were
you referring to?

> > At present, this is the kind of functionality that LASH aims to support.
> > The 'binding' occurs through the creation of consistently named ports,
> > which LASH will then connect appropriately according to the
> > configuration stored in the session.
>
> It is also what the Qjackctl patchbay supports partially.
> When the ports re-appear, it remakes the connection.
> The difference to really persistent ports is that in
> Qjackctl an app's ports are invisible while the app
> doesn't run. If Qjackctl would also display all ports
> in a patchbay allow you to modfy their connections in
> the normal connection dialog, it would be a near perfect
> emulation of 'persistent ports'. But such a thing is much
> more easy to write if ports are _really_ persistent in the
> server.

I think it would be a good to have a clear idea of what you're
proposing; please correct me where I'm wrong.  You would have a JACK
system that had no dynamic port connection capabilities and whose graph
was static.  The graph would be stored within some configuration file.
This could be hand-edited and of course there would be graphical
configuration editors, similar to patchage but which would operate
off-line and simply output a configuration file.  At runtime, clients
would bind to the statically defined ports.  No clients would be able to
take part in the system unless their presence was preconfigured within
the graph.

This seems like a nice system that would be robust and very usable.
There seems like only one thing to say against it: it isn't JACK.


--
Bob Ham <rah@...>


_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Fons Adriaensen-2]

On Sun, May 31, 2009 at 11:20:02PM +0100, Bob Ham wrote:

> I think it would be a good to have a clear idea of what you're
> proposing; please correct me where I'm wrong.  You would have a JACK
> system that had no dynamic port connection capabilities and whose graph
> was static.
> The graph would be stored within some configuration file.
> This could be hand-edited and of course there would be graphical
> configuration editors, similar to patchage but which would operate
> off-line and simply output a configuration file.  At runtime, clients
> would bind to the statically defined ports.  No clients would be able to
> take part in the system unless their presence was preconfigured within
> the graph.

No, that is definitely wrong.

There would indeed be a config file listing all 'existing'
ports and their connections, but it would still be possible
to do things dynamically and not just off-line.

But it would indeed not be 'Jack as we know it'.

(The following describes how things would look in a
 GUI context. Command line tools could do the same.)

Suppose you have started up with a config file that
has ports for clients A,B,C defined, and apps A and
B are actually running but C isn't.

C's ports would be 'grayed', indicating C isn't
running, but you could still modify the connections
made to them. When C is started it will use those
ports.

Now we start app D, which isn't part of the config.
The ports it tries to bind to will be created and
fully functional, but they are 'temporary' (they will
be removed when D terminates) and they are shown in a
distinctive color, e.g. red or purple.

The user then has the option of either leaving this as
it is, or of adding D's new ports to the current config.
Doing the latter means that if D terminates the ports
and their connections will remain, to be re-used when D
is stared again.  When adopting the ports the user also
has the option to leave them 'open' which means anybody
can make connections to them (via a service provided by
the control app), or to 'lock' them which means that
connections can be made only in the control app's GUI.

At any time the user can save the current config to a
named file, or load another one.

When loading a new config, ports that are active (the
corresponding app is running) but are not part of the
new config become 'temporary', as happened above for
D's ports, and the user has the option to add them to
the new current config or leave them as they are.

Now let's see how a session manager would use this.

Saving a session means:

- Requesting all apps, including the Jack controll app,
  to save their current config to the session.

Changing sessions means:

- Apps that are part of the old session but not of
  the new one are terminated.

- Apps that are in the new session only are started.

- All apps, including the Jack control app, are requested
  to load their configuration from the new session.

Loading a new session from scratch is just a special case
of changing sessions.


Ciao,


--
FA

Io lo dico sempre: l'Italia è troppo stretta e lunga.

_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[torbenh]

On Sun, May 31, 2009 at 11:20:02PM +0100, Bob Ham wrote:

> On Sun, 2009-05-31 at 11:11 +0200, Fons Adriaensen wrote:
> > On Sun, May 31, 2009 at 12:28:06AM +0100, Bob Ham wrote:
> >
> > > Possibly the veto is the way to go.  In fact, you could implement any
> > > restriction scheme you liked using a veto.  The key issue is that there
> > > must be no way to veto the veto, otherwise you're back at square one.
> >
> > It again is a distributed thing rather than centralised,
> > so while consistent with the current situation is goes
> > the wrong way. And it is *much* too easy to abuse, e.g
> > clients blocking removal of their self-made connections.
>
> Well, really this can already be done; clients can register port
> connection callbacks and monitor their own ports, reconnecting them if
> they're disconnected.  As far as I know, this hasn't been done.  Which
> isn't surprising as it kind of undermines one of main objectives of
> taking part in a JACK graph: the flexibility.
>
> I don't really see it as an issue of "abuse"; client authors are free to
> write whatever software they wish, and people are free to use or not use
> that software.  If we provide the facility for a port-connection veto,
> people will make use of that.  They may produce systems that work for
> themselves but not for others.  They may produce systems that work for
> everybody.

an normal jackapp has no business with connection vetos. its intended
for control apps only.

>
> I don't see this as a problem; the risk of some functionality
> facilitating systems that only work for some people isn't a risk in my
> eyes; nothing is lost.
>
> Having said that, I am curious as to what software would make use of a
> veto.  Torben, you mentioned you had identified two clients; which were
> you referring to?

lash, and something implementing connection ACLs.
lash wants to block bad autoconnect clients, while it loads up a
session.

a connection ACL controller i would like to be this an external tool,
because the discussion of what would be the best format to decalare
these ACLs would make me sick :D

> > > At present, this is the kind of functionality that LASH aims to support.
> > > The 'binding' occurs through the creation of consistently named ports,
> > > which LASH will then connect appropriately according to the
> > > configuration stored in the session.
> >
> > It is also what the Qjackctl patchbay supports partially.
> > When the ports re-appear, it remakes the connection.
> > The difference to really persistent ports is that in
> > Qjackctl an app's ports are invisible while the app
> > doesn't run. If Qjackctl would also display all ports
> > in a patchbay allow you to modfy their connections in
> > the normal connection dialog, it would be a near perfect
> > emulation of 'persistent ports'. But such a thing is much
> > more easy to write if ports are _really_ persistent in the
> > server.
>
> I think it would be a good to have a clear idea of what you're
> proposing; please correct me where I'm wrong.  You would have a JACK
> system that had no dynamic port connection capabilities and whose graph
> was static.  The graph would be stored within some configuration file.
> This could be hand-edited and of course there would be graphical
> configuration editors, similar to patchage but which would operate
> off-line and simply output a configuration file.  At runtime, clients
> would bind to the statically defined ports.  No clients would be able to
> take part in the system unless their presence was preconfigured within
> the graph.
>
> This seems like a nice system that would be robust and very usable.
> There seems like only one thing to say against it: it isn't JACK.

well... extend it with dynamic ports and you have jack + static ports ?

however... i strongly oppose anything requiring a config file which is
parsed by jack.

its impossible to come to consensus on config files.
and i think the dbus flamewar was enough for this year.


--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[torbenh]

On Sat, May 30, 2009 at 11:11:25PM +0200, Fons Adriaensen wrote:

> On Sat, May 30, 2009 at 12:15:57PM +0200, torbenh@... wrote:
>
> > On Thu, May 28, 2009 at 10:00:46PM +0200, Fons Adriaensen wrote:
>
> > > But IHMO this veto system has all it takes to create more
> > > miseray than it could solve - it basically allows any app
> > > to veto any connection, making it impossible to decide or
> > > configure this on any higher level. One would need a veto
> > > system agains clients abusing this to ensure things remain
> > > sane.
> > >
> > > If clients want to restrict access to their own ports that
> > > is OK. Anything else should not be the business of any
> > > particular client but be decided higher up.
> >
> > actually this is what i am fearing a bit too. iE dumb client vetoing
> > disconnect of their autoconnected ports.
> >
> > *shiver*
>
> *Shiver* indeed. And I wouldn't be surprised at all
> if some apps start doing this sort of thing.

Fons, you removed the part about, forbidding participating in the veto
system, for clients which have ports.

this may be a bit strict, but would effectively keep dumb clients out.


--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Fons Adriaensen-2]

On Mon, Jun 01, 2009 at 05:27:52PM +0200, torbenh@... wrote:

> Fons, you removed the part about, forbidding participating in the veto
> system, for clients which have ports.
>
> this may be a bit strict, but would effectively keep dumb clients out.

No, they could just open a second client. It's trivially easy.

Ciao,

--
FA

Io lo dico sempre: l'Italia è troppo stretta e lunga.

_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[torbenh]

On Mon, Jun 01, 2009 at 11:24:48PM +0200, Fons Adriaensen wrote:
> On Mon, Jun 01, 2009 at 05:27:52PM +0200, torbenh@... wrote:
>
> > Fons, you removed the part about, forbidding participating in the veto
> > system, for clients which have ports.
> >
> > this may be a bit strict, but would effectively keep dumb clients out.
>
> No, they could just open a second client. It's trivially easy.

lol... we are not talking about protection from hackers here.
we just want to make sure, its really hard for dumb people to abuse this
system.

>
> Ciao,
>
> --
> FA
>
> Io lo dico sempre: l'Italia è troppo stretta e lunga.
>
> _______________________________________________
> Jack-Devel mailing list
> Jack-Devel@...
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Fons Adriaensen-2]

On Tue, Jun 02, 2009 at 09:51:04AM +0200, torbenh@... wrote:

> On Mon, Jun 01, 2009 at 11:24:48PM +0200, Fons Adriaensen wrote:

> > On Mon, Jun 01, 2009 at 05:27:52PM +0200, torbenh@... wrote:
> >
> > > this may be a bit strict, but would effectively keep dumb clients out.
> >
> > No, they could just open a second client. It's trivially easy.
>
> lol... we are not talking about protection from hackers here.
> we just want to make sure, its really hard for dumb people to abuse this
> system.

But it isn't. We're not talking existing apps here,
they don't have the veto callback.

But if someone is adding the veto callback to use
it in a dumb way, all it takes is _one_ extra
line of code, which is a near copy of one he/she
already has, to bypass the no-ports restriction.
Something like 10 seconds extra work.

It will just become an idiom: if you want a
veto callback open a second client for it.

Ciao,

--
FA

Io lo dico sempre: l'Italia è troppo stretta e lunga.

_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Nedko Arnaudov]

Fons Adriaensen <fons@...> writes:

> But if someone is adding the veto callback to use
> it in a dumb way, all it takes is _one_ extra
> line of code, which is a near copy of one he/she
> already has, to bypass the no-ports restriction.
> Something like 10 seconds extra work.
>
> It will just become an idiom: if you want a
> veto callback open a second client for it.

Isn't single vetoer fixing this issue? ;)
User starts JACK, then starts the vetoer, then no other all can
supersede the existing vetoer. Just like X11 window managers work.

--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>


_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org