Re: [proposal] connection veto callback

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 

Re: PS: Qtractor wishlist

On Sun, May 31, 2009 23:15, Ralf Mardorf wrote:
> I guess that you're still busy by programming some 'standard' features,
> so I won't write to you 'please add this, please add that'.
>
> I wrote that it's a PITA, to do settings, because of seg faults. It's
> not too hard, it's able to work relaxed, so don't worry about this.
>

laetst qtractor 0.4.1 has a nasty bug that makes it crash half of the
times you load a session with midi tracks. it is even more probable to
crash if  you have a multi-core machine (cpus > 2). this nasty has been
already squashed in cvs.

you're welcome to check out and build from qtractor cvs (current version
as 0.4.1.1339) where bugs get nailed on a daily basis. you can also
experience a few new features as well ;)

otoh, i've read that you're using fluidsynth-dssi. depending on which
version of libfluidsynth you have installed, this seems to be a nasty
source of segfaulting in fluidsynth-dssi, most specially on session/plugin
closing. i've narrowed the issue to the obeservation that latest
libfluidsynth-1.0.9 is at stake; libfluidsynth-1.0.8 works flawlessly.

cheers
--

-- 
rncbc aka Rui Nuno Capela
rncbc <at> rncbc.org

Re: [proposal] connection veto callback

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.

> 

Re: [proposal] connection veto callback

On Sat, May 30, 2009 at 11:11:25PM +0200, Fons Adriaensen wrote:
> On Sat, May 30, 2009 at 12:15:57PM +0200, torbenh <at> gmx.de 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.

--

-- 

Re: [proposal] connection veto callback

On Mon, Jun 01, 2009 at 05:27:52PM +0200, torbenh <at> gmx.de 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.

Re: [proposal] connection veto callback

On Mon, Jun 01, 2009 at 11:24:48PM +0200, Fons Adriaensen wrote:
> On Mon, Jun 01, 2009 at 05:27:52PM +0200, torbenh <at> gmx.de 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 <at> lists.jackaudio.org
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

--

-- 
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language

Re: [proposal] connection veto callback

On Tue, Jun 02, 2009 at 09:51:04AM +0200, torbenh <at> gmx.de 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 <at> gmx.de 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

Re: [proposal] connection veto callback

Fons Adriaensen <fons <at> kokkinizita.net> 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 <at> lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

Re: [proposal] connection veto callback

Nedko Arnaudov <nedko <at> arnaudov.name> writes:

> 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.

s/all/app/

no other app

--

-- 
Nedko Arnaudov <GnuPG KeyID: DE1716B0>

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

Re: [proposal] connection veto callback

On Tue, Jun 02, 2009 at 03:31:35PM +0300, Nedko Arnaudov wrote:
> Fons Adriaensen <fons <at> kokkinizita.net> 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.

A single one would fix it, as long as it is the end
user who decides on what this single veto client is.

If it's 'the first one' then I'm pretty sure the
next release of <your favourite distro> will launch
one from the X11 init scripts, just as they do today
to force things like DesktopDirs, GnomeFuseDaemon,
and a collection of other things down your throat.

Second, if there is such a single app vetoing 
connections then all clients are at the mercy of
it, and it would be a much cleaner solution to have
just a single client being able to make (non-local)
connections.