[OSC_dev] Everyone Invited - SYNoscopy

[Jamie Bullock]

On Wed, 2008-12-17 at 11:11 +0100, Gaspard Bucher wrote:
<snip> 
> > A client could ensure that its addresss-space was compatible with a
> > server by querying the server for its address space definition, in the
> > same way that schema-compliant XML can be written with the assurance
> > that a schema-compliant reader will be able to open it.
> >
> > Jamie
> >
> 
> That's a good idea, but it won't bring us very far if we do not agree
> on some common behaviours (DTDs)... Anyway, it's a really good idea to
> have some kind os dtd.
> 
> I think we need more then just the "dtd" query: we need a standard way
> to get the answer back !

I hoped no-one was going to spot that obvious flaw ;-)

Seriously, I don't see how it is possible to do this in a standardised
way without making some assumptions about the underlying transport. Just
surmising, perhaps this is why these things were omitted from the
original spec, which aims to be transport independent?

> I propose something like "/reply_to" to register as return destination
> and /#osctype (DOCTYPE for osc) to get the "dtd".

Integra (a project I work on that uses OSC fairly heavily) uses a
'/register' message to register a client with the server, and gets back
a '/registered' message in confirmation (although /reply_to is equally
good semantically). It assumes an IP-based protocol (UDP or TCP), so:

/register 10.0.0.3 4445

Results in:

/registered 10.0.0.3 4445

>From that point the messaging is bi-directional, with the current caveat
that all registered clients receive all notifications. This isn't really
ideal, and in future versions we'd like to add functionality for
*independent* addressing of multiple clients.

> The answer should be an url like : /controller/lemur/v3. This would
> mean it responds to common methods for "/controller" and specialized
> methods for "/controller/lemur" with even more specialized methods for
> "/controller/lemur/v3".

That sounds reasonable. Would it be possible to discover the entire
address space for a server via this method? If so how do in envisage it
working?

In Integra we support a '/nodelist' message, which results in a series
of replies, one for each supported OSC address, e.g.

client: /nodelist
server: /delay.1
        /delay.1/delay-time 
        /delay.1/feedback 
        /distortion.1 
        /distortion.1/gain
	etc.

(The individual node (delay.1) namespaces are added to the server
dynamically when processing modules are loaded, so we need this query
mechanism). And for information about a given node:

client: 
/info /delay.1/delay-time
server: 
/Delay/delay-time/minimum 0
/Delay/delay-time/maximum inf
/Delay/delay-time/default 100
/Delay/delay-time/unit milliseconds
/Delay/delay-time/type float 
/Delay/delay-time/description "The amount of time the input is delayed
by before being sent to the output"
/Delay/delay-time/documentation
"http://www.thewhippinpost.co.uk/tools/delay-time-calculator.htm"

This way a client can build up a complete picture of the server through
query. This is great for dynamically generating GUIs etc.

Clearly some of the above is specific to our project, and requiring that
servers provide all of this information as standard would be overkill.
But perhaps as a minimum the server should be able to supply the address
space '/nodelist' and the typestring for a given node in response to the
'/info' message.

WDYT?

> This way we could build incrementally on top of some basic features,
> with an API definition available for an application's very specific
> needs.

A kind of pseudo inheritance?

Jamie

-- 
www.postlude.co.uk
http://www.linkedin.com/in/jamiebullock