[OSC_dev] Everyone Invited - SYNoscopy

[Gaspard Bucher]

On Wed, Dec 17, 2008 at 10:42 AM, Jamie Bullock <jamie at postlude.co.uk> wrote:
> 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
>

That's a good idea, but it won't bring us very far if we do not agree
on some common behaviours (DTDs)... Anyway, it's a really good idea to
have some kind os dtd.

I think we need more then just the "dtd" query: we need a standard way
to get the answer back !

I propose something like "/reply_to" to register as return destination
and /#osctype (DOCTYPE for osc) to get the "dtd".

The answer should be an url like : /controller/lemur/v3. This would
mean it responds to common methods for "/controller" and specialized
methods for "/controller/lemur" with even more specialized methods for
"/controller/lemur/v3".

This way we could build incrementally on top of some basic features,
with an API definition available for an application's very specific
needs.

What do you think ?

Gaspard