[OSC_dev] Everyone Invited - SYNoscopy
Jamie Bullock
jamie at postlude.co.uk
Wed Dec 17 12:54:28 PST 2008
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.
Jamie
--
www.postlude.co.uk
http://www.linkedin.com/in/jamiebullock
More information about the OSC_dev
mailing list