On Mon, Jan 26, 2004 at 07:21:47 +1100, rd(a)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