Re: [linux-audio-dev] [RFC] Lite OSC API

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] [RFC] Lite OSC API
From: Steve Harris (S.W.Harris_AT_ecs.soton.ac.uk)
Date: Mon Jan 26 2004 - 11:10:59 EET


On Mon, Jan 26, 2004 at 07:21:47 +1100, rd_AT_alphalink.com.au wrote:
> I am afraid have gotten to your OSC messages a bit late, I can only
> read lists at web archives at present and the jack lists have been
> down...

No problem.
 
> > * No service discovery. This is a big deal, but can be solved /if/ we
>
> I don't know of a database, which I guess is not a good situation.
> CNMAT might be interested in doing the basic administration required
> for a port register. I think that a database of static port numbers
> is preferable to a dynamic system *if* it is workable. If a dynamic
> system were neccessary it should be implemented as an OSC server! I
> am actually not exactly sure what you mean by service discovery?

After thinking about it a bit more I dont think static can work, there
just aren't enough free, or reliably free ports.

A service discover service is just something that listens out for
registration requests (on a known port) and you say what (public) methods
you support. The service discover service will then poll you to make sure
youre still alive every now and then and you can say when you add or
remove methods.
 
> > I'm very happy to discussus a GPL'd library implementation or
>
> I have had to do some work on the OSC implementation I have been
> using
> in order to address two issues. I think you will need to address
> these with liblo also. They are: 1. type coercion and 2. variable
> argmument messages.
>
> I am going to attach the note I wrote about the implementation below,
> which describes these in detail, but briefly on type coercion:
>
> Given the message shape ("/foo/bar" "fi") as in the testlo.c file, a
> receiver should match not only ("/foo/bar" "fi" 2.0 23) but also
> ("/foo/bar" "ii" 2 23) and ("/foo/bar" "if" 2 23.0) and in fact all
> other possible numerical encodings, and provide them to the handler in
> the form requested.

OK, interesting - it wouldn't be a huge task, but why is this a good idea?
It just seems inconvienient for the recipient and I dont know of any other
RPC mechanisms where its allowed (or wanted). In the case of typetag-less
messages it would be difficult to handle, you'd have to try to discover
the type of the argument by inspection. Do you have a link to a rationale
for this?

Variable argument messages can be handled as a whole, eg. the
generic_handler takes messages with any typetag. But I guess you mean
things like "fi*s". That could be useful.
 
> The work I have done *only* provides the byte string decoder and
> encoder, but it does support all the extended basic OSC types and
> numerical and string coercion. I think you could use it as is if you
> wanted, or of course just take whatever you need. I will happily
> implement/apply any changes/fixes required to make it usable for you.
> The implementation is in the file 'osc.c' in the jack.clock or
> jack.scope archives at <http://www.alphalink.com.au/~rd>. It
> works for me but is otherwise untested!

OK, thanks I'l have a look at it, sorry I didnt realise you had any
generic code.
 
> Apart from the above the design looks good, although personally I
> agree with James McCartney, see SC3 or recent post to OSC_dev, that
> combining the verb and the subject in the address is a bad idea, and
> would prefer to see a library that discourages that use ;) (This would
> also make the handler type declarations simpler...)

I agree that combining the verb and subject seems a little odd, but that
is the sitatuion in the web services world too - when neccesary they get
round it by adding a verb argument eg ("/my/path", "verb", ...), which is
a useful cnvention but its not neccesary to set it in stone.
 
> TN-16 - OSC C-Language Parser/Constructor

Looks good.
 
> The design requirements are that the library should:
>
> * be thread safe and re-entrant
> * not allocate any memory or call any other non-RT safe procedure

This one is inherantly not possible, youre doing i/o operations.

> * handle arbitrary length and variable length messages
> * provide all reasonable type coercion [2]

This one I am not convinced about. Polymorphism I can see the use of, but
I've always been more of a strongly-typed guy :)

- Steve


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Mon Jan 26 2004 - 11:14:11 EET