[OSC_dev] Everyone Invited - SYNoscopy

Jamie Bullock jamie at postlude.co.uk
Wed Dec 17 01:42:35 PST 2008


On Tue, 2008-12-16 at 11:55 -0800, Andy W. Schmeder wrote: 
> On Dec 16, 2008, at 7:59 AM, Gaspard Bucher wrote:
> 
> > What are the reasons why these issues are not part of osc and have to
> > be solved for every new project with the risk of everyone
> > reimplementing possibly incompatible wheels ?
> 
> OSC was formulated with certain design criteria in mind.  One of them  
> is that it is stateless, and another is simplicity.  The justification  
> for the former is somewhat technical so I won't elaborate right now.   
> Perhaps the main reason that OSC has been so successful is because of  
> its simplicity...  and, if we added a bunch of required messages for  
> "standard interoperation" functions, etc, then the implementation  
> complexity would be much greater.  Also, there are some applications,  
> such as SuperCollider, where such things actually might be so complex  
> as to be infeasible.
> 
> The closest analogy is XML, where an application that "uses XML"  
> guarantees no compatibility whatsoever with any other application that  
> "uses XML" (just like OSC), it only guarantees compatibility with XML  
> parsers.  To actually get stuff done, the W3C has built a huge empire  
> of protocols that live on top of XML, for example, SOAP, XHTML,  
> XForms, and so on.
> 

This is a really interesting . For me highlights the 'missing
ingredient' from OSC, which is an equivalent to a DTD or schema for a
given address space.

I've never really been a fan of standardising address spaces (e.g. SYN),
however, it would be useful to have a standard extension to the protocol
for address space *definitons*. I think people have already looked into
this Jazzmutant? CIRMMT? 

IMO, it would be useful to have a set of standard methods that a server
*must* provide in order to be OSC protocol compliant. These would
provide information about the server's supported addresses and message
formats. Thus alleviating the need for ad hoc documentation because a
server would in effect become self-documenting. This would make it a lot
easier for people to develop standards on top of OSC, equivalents of
SOAP, XHTML etc as you say.

A client could ensure that its addresss-space was compatible with a
server by querying the server for its address space definition, in the
same way that schema-compliant XML can be written with the assurance
that a schema-compliant reader will be able to open it.

Jamie

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




More information about the OSC_dev mailing list