[OSC_dev] Application Profiles

Jamie Bullock jamie at postlude.co.uk
Mon Dec 22 05:01:07 PST 2008


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


-- 
www.postlude.co.uk
http://www.linkedin.com/in/jamiebullock

-- 
www.postlude.co.uk
http://www.linkedin.com/in/jamiebullock




More information about the OSC_dev mailing list