[OSC_dev] Everyone Invited - SYNoscopy

[Stephen Sinclair]

On Wed, Dec 17, 2008 at 3:54 PM, Jamie Bullock <jamie at postlude.co.uk> wrote:
> On Wed, 2008-12-17 at 15:31 -0500, Stephen Sinclair wrote:
>> 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?
>
> The semantics of /register are that the client registers itself for
> responses from the server. In Integra it's optional, i.e. the client can
> just assume that the messages it sends have been received and acted
> upon. So /register is still relevant for TCP connections although the IP
> address/port are obviously redundant and should therefore be optional.
> (Note to self: this isn't documented anywhere)
>
>> This /register stuff doesn't seem to bode well for the "statelessness"
>> goal of OSC.
>
> I disagree. I think it's reasonable for OSC to remain stateless, with
> other stateful or stateless protocols built on top of it.

That's true, I guess I'm wrong.

A basic thing about OSC is that it seems to be itself just a transport
layer for other protocols. :)

Actually I guess in the OSI model it is the Presentation layer (6),
but not the Application layer (7).

I often think of the lack of semantics in OSC as similar to the
difference between MIDI and General MIDI.  MIDI itself was certainly
useful, but the latter is what _really_ made MIDI take off in the
industry.

Perhaps the problem we have here is that due to a lack of an OSC
version of General MIDI (because it tackles a much larger problem set
than "keyboard instruments"), we have many different projects
implementing their own semantic layers.  Maybe one day some of these
can become their own standard that other projects can adhere to,
within a certain problem domain.  (Like the proposed Open Media
Control for example.)

Steve