[OSC_dev] Fwd: Application Profiles: oscplanet

[Nicholas J Humfrey]

> 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

I like the use of a dot to indicate a meta-method. Although part of me  
wants to namespace this incase someone comes up with a different/ 
better way of doing things in the future. I know we are kind of going  
round in circles here...

OSC Planet namespace examples:
-> /oscp/reply_to (ps) 4444 localhost
-> /oscp/info (s) /some/url


> 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

-> /oscp/list (s) /
<- /oscp/reply (ssss) /oscp/list / /deck/ /playlist

By including the query in the reply, we know what it is a reply to.


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

I like the use of /.reply but I don't totally understand the example  
you gave.
One thing I have been thinking about is that maybe we should just be  
using 'get' and 'set' methods.

-> /oscp/get (s) /mixer/volume
<- /oscp/reply (si) /mixer/volume 10
-> /oscp/set (si) /mixer/volume 20


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

-> /oscp/info (s) /some/method
<- /oscp/reply (ss) /some/method "This method does something"


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

While I have used 'oscp' in my examples, I am not overly keen on the  
name Planet. Maybe I am just being boring but could something be  
descriptive be used instead?

OSC Replies?
Meta OSC ?
OSC Query and Response ?
OSC Introspection ?

Planet just seems to be too all-encompassing.

Sorry for being difficult - I am looking forward to implementing some  
of this stuff!


nick.