Re: time for port aliases

Le 23 avr. 07 à 18:09, Rui Nuno Capela a écrit :

> Paul Davis wrote:
>> I'm about ready to wrap up the v1.0 API by adding
port aliases  
>> which i
>> believe will serve two purposes:
>>
>>    1) they are generally useful
>>    2) they will allow us to migrate away from the
current
>> backend-specific names in favor of something more
generic, without
>> breaking any client behaviour
>>
>> my only dilemma is the best way to implement them.
i don't want to  
>> do a
>> client/server roundtrip to lookup aliases, which
means they need  
>> to live
>> in shared memory. this suggests (to me) 2
possibilities:
>>
>>    a) a new shared memory "chunk" that
contains a list of aliases
>>    b) add a fixed number of alias slots to the
existing port  
>> structure
>>
>> (b) is a bit of a kludge, and limits the aliases
per port BUT at the
>> same time it avoids more substantive changes to the
overall design in
>> favor of a bit more memory allocation. and in
reality, the number
>> of aliases per port is likely to be zero, one or
two at the outside.
>>
>> (a) is cleaner but requires that each client
attaches to a new shared
>> memory segment and adds another set of cleanup
responsibilities to
>> jackd.
>>
>> i also wonder how well either of these will fit
with jackdmp.
>>
>> comments?
>>
>
> shm cache indirection should suffice,... but that would
break 0.x  
> ABI, I
> think :/ what I mean is that literal string names
should _not_ ever
> beeen in shared mem, just some kind of handles/ids,
mapped to outside
> .conf/.ini/registry/properties file or whatever.
Yeah...just a  
> quick thought
>
> BTW, qjackctl already has some kind of client+port
aliasing (1:n
> renaming), but this subject would be a plus and a
smasher 
>
> I'm also edging on doing the qjackctl migration dance
towards Qt4, so
> doing something like so... disruptive, would come at
hand, eh eh ~

Yeeesss !!

jackdmp on Windows "may" finally become
usable....

Stephane

>
> Cheers
> -- 
> rncbc aka Rui Nuno Capela
> rncbcrncbc.org
>
>
------------------------------------------------------------
---------- 
> ---
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2
express and take
> control of your XML. No limits. Just data. Click to get
it now.
> http://sourcefor
ge.net/powerbar/db2/
> _______________________________________________
> Jackit-devel mailing list
> Jackit-devellists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jackit-dev
el


------------------------------------------------------------
-------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and
take
control of your XML. No limits. Just data. Click to get it
now.
http://sourcefor
ge.net/powerbar/db2/
_______________________________________________
Jackit-devel mailing list
Jackit-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jackit-dev
el

Paul Davis wrote:
> I'm about ready to wrap up the v1.0 API by adding port
aliases which i
> believe will serve two purposes:
> 
>    1) they are generally useful
>    2) they will allow us to migrate away from the
current
> backend-specific names in favor of something more
generic, without
> breaking any client behaviour
> 
> my only dilemma is the best way to implement them. i
don't want to do a
> client/server roundtrip to lookup aliases, which means
they need to live
> in shared memory. this suggests (to me) 2
possibilities:
> 
>    a) a new shared memory "chunk" that
contains a list of aliases
>    b) add a fixed number of alias slots to the existing
port structure
> 
> (b) is a bit of a kludge, and limits the aliases per
port BUT at the
> same time it avoids more substantive changes to the
overall design in
> favor of a bit more memory allocation. and in reality,
the number
> of aliases per port is likely to be zero, one or two at
the outside.
> 
> (a) is cleaner but requires that each client attaches
to a new shared
> memory segment and adds another set of cleanup
responsibilities to
> jackd.
> 
> i also wonder how well either of these will fit with
jackdmp.
> 
> comments?
> 

shm cache indirection should suffice,... but that would
break 0.x ABI, I
think :/ what I mean is that literal string names should
_not_ ever
beeen in shared mem, just some kind of handles/ids, mapped
to outside
.conf/.ini/registry/properties file or whatever. Yeah...just
a quick thought

BTW, qjackctl already has some kind of client+port aliasing
(1:n
renaming), but this subject would be a plus and a smasher


I'm also edging on doing the qjackctl migration dance
towards Qt4, so
doing something like so... disruptive, would come at hand,
eh eh ~

Cheers
-- 
rncbc aka Rui Nuno Capela
rncbcrncbc.org

------------------------------------------------------------
-------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and
take
control of your XML. No limits. Just data. Click to get it
now.
http://sourcefor
ge.net/powerbar/db2/
_______________________________________________
Jackit-devel mailing list
Jackit-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jackit-dev
el

On Mon, 2007-04-23 at 17:09 +0100, Rui Nuno Capela wrote:

> 
> shm cache indirection should suffice,... but that would
break 0.x ABI, I
> think :/ 

no clients are ever permitted access to any JACK data
structures. this
does not break any ABI. libjack is the big fat insulating
layer here.

> what I mean is that literal string names should _not_
ever
> beeen in shared mem, just some kind of handles/ids,
mapped to outside
> .conf/.ini/registry/properties file or whatever.
Yeah...just a quick thought

we have the port and client names in shared mem? what' the
issue?

> I'm also edging on doing the qjackctl migration dance
towards Qt4, so
> doing something like so... disruptive, would come at
hand, eh eh ~

always aiming to please the customer 

--p



------------------------------------------------------------
-------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and
take
control of your XML. No limits. Just data. Click to get it
now.
http://sourcefor
ge.net/powerbar/db2/
_______________________________________________
Jackit-devel mailing list
Jackit-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jackit-dev
el