Re: [Jack-Devel] Any plans for meta-data API in jack2?

On Sunday 15 December 2013 16:44:37 Stéphane Letz wrote:
> > I realize it might be a bit of work, although there's JACK1 code for
> > reference. If no one is working on it, I can try and get it done myself.
> > 
> > @Stéphane:
> > If I make a patch for this (github pull request), will it be accepted?
> 
> If done well sure….

Hi Filipe,

you could probably recycle at least a bit from JACK iOS for that. You know, 
you have to pass data between clients and server and ATM the protocol of JACK2 
(common/JackRequest.h) uses only messages of fixed size (fix at compile time). 
In JackRequest.h you will see that each message has its own struct, and they 
are simply copied as so called POD ("Plain Old Data") types i.e. with 
memcpy(). However that won't work for implementing that meta data API, since 
the data you pass around can be of arbitrary size, but is definitely not known 
at compile time.

So you could at least have a look at how JACK iOS solves this particular 
problem (it was used for the "custom data API" of JACK iOS). I.e. in 
JackRequest.h you will see that there is an additional virtual method

	virtual bool IsFlatStruct() { return true; }

which is then overridden by the respective message structs to let the network 
code know whether the respective message is a POD type (so it can be simply 
memcpy()ied) or a message with dynamic size only known at runtime instead.

"struct JackCustomDataPublishRequest" is an example of such a message with 
dynamic size (in the same header file - JackRequest.h).

Then JACKiOS has some tiny helper class "JackChannelIOBuffer" 
(ios/JackChannelIOBuffer.h) which simply provides a streaming solution for 
those dynamic size messages and in ios/JackMessagePortServerChannel.h and 
ios/JackMessagePortClientChannel.h that helper class JackChannelIOBuffer is 
used to pass those dynamic size messages between client and server.

About persistence of the meta data API: not sure if that's really necessary. 
IIRC Paul made it persistent in JACK1 with a Berkeley DB implementation. You 
could probably leave that out for a start and just implement a solution where 
the data is kept in RAM by the server with simple STL container(s), and lost 
when the server terminates. Keep it simple. ;-)

CU
Christian

1387142678.652_0.ltw:2, <201312152232.25441.schoenebeck at crudebyte dot com>