[OSC_dev] Application Profiles

[Jamie Bullock]

On Sun, 2008-12-21 at 20:41 +0100, Gaspard Bucher wrote:
<snip>
> 2. libosc limitations
> 
> We need to conform to OSC spec and make things easy to implement and
> process. This means we need to avoid ambiguities and superfluous
> parsing. We have two choices here.
> 
> a. use a special syntax for "meta" methods (get information, type, etc
> = equivalent of ".h" files in C)
> 
> The existence of this special syntax should not make it too heavy to
> process incoming messages. I propose Gabriel's idea of using
> "/some/url(info)", because the trailing ")" is easy to detect and
> means "hey osc processor, this is a special url". It also conforms to
> OSC spec.
> 
> b. use special method names
> 
> This has the advantage of leaving the osc parser out of the "meta"
> thing altogether, but it means you have to register all the "meta"
> methods: /foo/bar/.info, /foo/bar/.type, etc.

c. use special server methods. I call these 'static' methods, because in
Integra they are the only methods that are not generated dynamically at
runtime.

/info /foo/bar

This has the advantage of being super-easy to parse on the server, and
has the nice effect that you get a top-level 'meta' address space
(/info, /reply_to etc.) before you have added any 'application-specific'
methods. More details in this post:  http://tr.im/2jl4
 

<snip>
> What I would love to have is:
> 
> a. you add some service on the network (a controller full of buttons
> and sliders / a software like VLC / anything)
> b. rubyk sees your new service because of zeroconf automatic service discovery
> c. hey ! this thing conforms to some very minimal things rubyk understands
> ===>
> d. I can present an osc browser of the new service to the rubyk user,
> with help messages and such
> e. the user can put a slider on the rubyk patcher and connect it to
> the element in the browser
> f. moving the slider, changes the value of the remote thing
> g. when something else updates the remote thing, the slider in rubyk
> moves as well

I think these are good goals!

> 5. conclusion
> 
> Everyone is free to ignore this effort and the obvious benefit for the
> end user. But if some of this succeeds, he/she will produce this
> disappointing printer wich just doesn't want to work without the
> burden of installing drivers in a world where all the rest just plays
> together smoothly.
> 
> In order to produce the upper mentioned "browser", we need:
> 
> a. /reply_to
Agree!

> b. /some/url/  ==> trailing "/" = listing
I prefer /namespace /some/url. Reasons: 

1. Meta/static methods live in the server's top-level address space. I
think this makes for a cleaner interface than having them scattered all
over the address space. "/" seems anti-DRY somehow.
2. It's easier to implement
3. It carries more semantic information

However, I think the trailing slash idea is OK, and would happy to add
it to Integra if there's some consensus.

> c. /some/url   ==> get value
Agree!

> d. /some/url 4 ==> set value
Agree!

> e. /some/url/.info ==> human readable message
Again, I prefer

/info /some/url

...reasons same as above (minus 3!)

> f. use zeroconf !
Agree!


> That's not such a deal and I'm ready to provide just the code for this
> (with oscpack and zeroconf) in a simple to use package if there is a
> need.

Great!

Jamie

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