[OSC_dev] Fwd: Application Profiles: oscplanet

[salsaman at xs4all.nl]

On Mon, December 22, 2008 17:26, Gaspard Bucher wrote:
>> 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
>

Why would /reply_to need a . before it ? It is just a normal command, its
not a meta-operation on other nodes.



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


As I have pointed out several times now, this is ambiguous. Are you
setting /midout/channel to 4.5, or are you querying the value of
/midout/channel,4.5 ?



Gabriel.