[OSC_dev] Application Profiles
salsaman at xs4all.nl
salsaman at xs4all.nl
Mon Dec 22 03:21:09 PST 2008
On Mon, December 22, 2008 10:22, Jamie Bullock wrote:
> 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
>
I like this idea. Adding new top level nodes seems much nicer than adding
subnodes.
I also like the way your /nodelist shows a list of nodes and their values.
>
> <snip>
>> a. /reply_to
> Agree!
>
>> 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
As I pointed out, this is hardcoded to do something in libOSC (probably
not what we want), so this should be avoided.
>
> However, I think the trailing slash idea is OK, and would happy to add
> it to Integra if there's some consensus.
>
>> c. /some/url ==> get value
> Agree!
>
>> d. /some/url 4 ==> set value
> Agree!
This is broken as I have pointed out - does not work if get and set have
different parameters, unfortunately. I showed an example where this causes
ambiguity.
It is physically impossible for me to implement this schema in my
application. I think we should avoid schemas which are physically
impossible.
>
>> e. /some/url/.info ==> human readable message
> Again, I prefer
>
> /info /some/url
>
> ...reasons same as above (minus 3!)
>
>> f. use zeroconf !
> Agree!
>
>
>> That's not such a deal and I'm ready to provide just the code for this
>> (with oscpack and zeroconf) in a simple to use package if there is a
>> need.
As I have pointed out already oscpack is C++, so it is no good for my
project or many others.
I have no experience of using zeroconf, so I can`t really comment on this
part. But doesn`t dbus have some kind of service registration ? Would that
be a better choice ?
Gabriel.
http://lives.sourceforge.net
More information about the OSC_dev
mailing list