[OSC_dev] Everyone Invited - SYNoscopy

salsaman at xs4all.nl salsaman at xs4all.nl
Wed Dec 17 13:19:00 PST 2008


On Wed, December 17, 2008 21:54, Jamie Bullock 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.
>
> Jamie




This is good !

My latest suggestion is this -


client sends: /reply_to,<port>,<host>
host responds with e.g.: /omc/lives

This eliminates the need for ping, also eliminates the need to explicitly
get a host name.



Other stuff we are discussing:

/bish/bosh/#info - returns human readable description
/bish/bosh/#dumptree - dumps OSC tree below /bish/bosh

/bish/bang - if an action, does /bish/bang

/bish/var,123 - if a variable, sets the value of /bish/var to 123 and
returns the current value.



My suggestion (I think we need this):
/bish/bosh/#variables : return list of variables for /bish/bosh (or empty
string if /bish/bosh is an action).



And that's about it !


Gabriel "salsaman",
http://lives.sourceforge.net




More information about the OSC_dev mailing list