[OSC_dev] Fwd: Application Profiles: oscplanet

[salsaman at xs4all.nl]

On Mon, December 22, 2008 21:47, Nicholas J Humfrey wrote:
>
>> 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
>

Please use /.nodelist


Also the typetags must be an array. I have discovered this now on
implementing similar. For example (using your syntax):

/oscp/reply_to ("","i","si")

another example form my code would be:

/video/fps/set ("f","i")

because it takes int or float as a parameter.

As a final example:

/effect_key/parameter/value/set ("i","i","v")

because it takes (int key) (int param_number) (variable value(s))

we need the "v" type because the type and number of value depends on the
parameter type.

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

Yes, I agree totally - not only because of the ambiguities I have pointed
out, but also because you can have different type tags for /get and /set.

/set can have a choice of type tags, whereas we should limit /get to just
one set of type tags.

Other advantages - you can see if something is a command - it has no /get
or /set, you can see if something is readonly - it has a /get but no /set.



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

Erm....how about OMC :-) ?


I also want to apologise if I am being difficult.

However it seems like my app is set up in a very different way from others
- a lot of this is down to simply the way the program works.


Regards,
Gabriel.
http://lives.sourceforge.net