[OSC_dev] Application Profiles

[salsaman at xs4all.nl]

On Mon, December 22, 2008 14:01, Jamie Bullock wrote:
> On Mon, 2008-12-22 at 12:21 +0100, salsaman at xs4all.nl wrote:
> <snip>
>> >> 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.
>
> The problem we have is that in general OSC doesn't provide any
> information about what an address represents. I.e. your argument about
> '/play' being ambiguous, is equally valid for addresses *with*
> arguments: e.g. how do you distinguish the attribute set vs the method
> call here:
>
> /piece/title 'Foo'         <- Setting a value
> /piece/rewind '5' 'bars'   <- Calling a method
>
> It is only the semantics of the address that gives us a clue whether we
> are setting or calling.
>
> Perhaps we should think of the implicit 'get' as returning the current
> *state* associated with a given address, where the state can be the
> value associated with an attribute, or some other representative value.
> I'm thinking here along the lines of Python's 'repr()', which returns
> the canonical string representation of an object:
>
> x = 2
> x
> => 2
> map
> => <built-in function map>
>
> So methods associated with both of these addresses return the current
> state of what the address represents:
>
> /piece/title          <- Getting a value
> -> 'Foo'
> /piece/play           <- Calling a method
> -> 'play method'
>
> I don't see what we gain by adding an explicit 'get':
>
> /piece/title          <- Presumably this does nothing?
> /piece/title/get
> -> 'Foo'
> /piece/play           <- Calling a method
> ->                    <- Presumably no return value
> /piece/play/get
> -> 'play method'      <- ??
>
> It just seems to add complexity, with no real advantage IMO.
>
>> It is physically impossible for me to implement this schema in my
>> application. I think we should avoid schemas which are physically
>> impossible.
>
> Why is it physically impossible? Is this something specific to your
> application (or OSC implementation), or something in the spec?
>
> Jamie
>

I gave an example:

/foo/bar,5

- is ambiguous in my application, I could be setting the value of /foo/bar
to 5, or requesting the value of /foo/bar,5

At first I also liked the idea of not having /get and /set, but the above
problem became apparent when I tried to implement it.


Also, having /get and /set is nice, you know immediately if /foo/bar is a
property or a command, and if it is a property you also know whether it is
readonly.


Gabriel.