[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