[OSC_dev] Fwd: Application Profiles: oscplanet

Mon Dec 22 23:27:16 PST 2008

As we have discussed, there are numerus advantages of avoiding
cluttering the tree with ".../get", ".../set", ".../info", etc:. One
of them is the maintenance of a dynamic large trees (create, rename,
move, destroy).

I do not have the time right now to go into all the details, but I
propose that you just make your application work with the library you
have and the current code you have created and when I release the
"oscplanet" library, we can compare how they behave, if it's easy to
parse, add urls, etc. If "/get '/some/url'" proves to be better
because the other solution just doesn't work in some situations, I
will change the library, no problem.

Gaspard

On Mon, Dec 22, 2008 at 11:03 PM,  <salsaman at xs4all.nl> wrote:
> 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
>
>
> _______________________________________________
> OSC_dev mailing list
> OSC_dev at create.ucsb.edu
> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev
>