[OSC_dev] Everyone Invited - SYNoscopy

Stephen Sinclair radarsat1 at gmail.com
Wed Dec 17 12:31:11 PST 2008


On Wed, Dec 17, 2008 at 1:48 PM, Jamie Bullock <jamie at postlude.co.uk> wrote:
> 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



Since we're talking about transport independence, I just wanted to
point out that the above is useful for a UDP scenario, but in TCP you
know who you're talking to as long as the connection remains alive.
Does /register apply in either case?

This /register stuff doesn't seem to bode well for the "statelessness"
goal of OSC.


Steve


More information about the OSC_dev mailing list