[OSC_dev] Fwd: Application Profiles: oscplanet

[Gaspard Bucher]

> 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
Fine ! I want my parser to be fast and putting all meta in special
urls makes it faster and cleaner. In rubyk, most of the objects live
at the root "/". Could we move all meta methods in something like
"/osc" or "/meta" or "/~" or "/:" ? If we do not do this, I will have
to move the nodes and since node methods are called 1000x more often
then meta methods (only used during setup), I think they should get
shorter urls. If you don't mind that we use some kind of prefix,
either as a container or just on the methods themselves, I think "/."
is simple and easy. Many projects have some meta content at the root
contained in a ".xxx" (.git, .profile, .ssh, etc) so this should be
quite natural.

/.info /some/url
/.reply_to


> <snip>

>> a. /reply_to
> Agree!

Becomes /.reply_to

>
>> 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

I think it's a good idea to forget about meta things in special
syntaxes (makes the processor slow), even for tiny things such as
trailing "/". Let's go for:

/.list /some/url

Or even

/.ls /some/url


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

I *really* need this simple set/get for multiple gui mirroring. In a
previous email, someone said that replies could be understood as
actions if they have exactly the same format and are sent on i2c lines
or simple transmission where everyone gets everything. To avoid this,
I propose that answers use the following syntax:

query: /midiout/channel 4.5
reply: /.reply "/midiout/channel" 4  (type = "sx" where x is the type
of the returned value)

This means that we need a "/.reply" parser that will receive all
answers, but it's better then the confusion that can arrise when it's
not clear whether the url is a notification of a change or the action
itself. This kind of confusion can make programming more complex or
you will have your sliders oscillate from one app to another because
of network lag. Using "/.reply" with a string and a value avoid this
totally. If someone really wants the previous behaviour, it's very
easy to implement a "/.reply" method that just sends the url and
parameter back to it's osc tree.

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

/.info /some/url

>
> ...reasons same as above (minus 3!)
>
>> f. use zeroconf !
> Agree!
>
I will register a service name
(http://www.dns-sd.org/servicetypes.html) for apps / hardware that
will conform to this minimal osc based methods under

oscplanet

I like the universe metaphor for large and complex setups with many
things sending signals to each other.

Is that ok for you ?

Start of "oscplanet" definition: http://rubyk.org/en/article162.html

Gaspard

PS: oscplanet library

Since it will be most useful to have an easy way to enable these
features in any application / hardware, I will try to extract the code
to do this from rubyk and make it a library that could be used from
"C" and "C++". The library will be as minimal as possible, it will be
called "oscplanet" and will use oscpack. There will be a simple way to
register new urls and implement callbacks for the meta methods listed
here. It will also contain the zeroconf stuff. I will start working on
this library after winter holidays (begin of January).