[OSC_dev] liboscqs

[Gaspard Bucher]

I have taken a quick look at oscqs and although some things are close
to what has been discussed ("/reply", "/osc/schema", trailing "/" for
listing) but there are some differences. Some of these differences
don't really matter (naming conventions), but some other take routes
that we have arguments agains. As Gabriel noted ("meta url" vs
"methods at end"), meta urls in the same namespace as normal methods
("/foo/bar/documentation") and some things that only exist because of
the namespace clutter: "/some/url/current-value".

Does anyone know which application actually uses this ?

The strength of "oscit" or whatever we call it will surely be that it
will come out of real needs from real applications made by real users.
This is a very rare situation and that should encourage us in our
effort and that could be really successful (if we work hard and are
patient) because it's something we *need* (and I need it before the
end of January).

For the name thing, Quentin Berthet, a friend, suggested "oscope".
It's quite nice. Someone could come up with a retronym. But the
"scope" idea is really interesting: it reflects both the radar that
discovers other things to play with and the namespace idea.

Can we pick "oscope" for now (we may change later) ? I really need
names to start working on things (it's a weirdness of by brain).

Gaspard

PS: Jamie, Gabriel: I put your names on the
"http://rubyk.org/en/article162.html" page.

On Tue, Dec 23, 2008 at 8:39 PM,  <salsaman at xs4all.nl> wrote:
> On Tue, December 23, 2008 17:49, Gaspard Bucher wrote:
>> On Mon, Dec 22, 2008 at 9:21 PM, Nicholas J Humfrey <njh at aelius.com>
>> wrote:
>>> I have just remembered about Martin Habets' liboscqs which is build on
>>> top of liblo:
>>>
>>> Schema for OpenSound Control Query System
>>> http://liboscqs.sourceforge.net/schema/OSCQS-schema-0.0.1.pdf
>>>
>>> Oh so much duplication of effort!
>>>
>>> We need to get this sorted out once and for all.
>>>
>>>
>>> nick.
>
>
> Had a quick skim through of this - looks mostly OK, but:
>
> - you don't have the reply_to command that we discussed - so I suppose you
> always reply to the sender, which is OK - theoretically
>
> but I see you can add an output patch - is that something similar ? Is it
> only for status messages or for notifications as well ?
>
> - you only support one set of type_tags - for me it is important to have a
> choice of type tags : you can fix this very simply by returning a list of
> strings instead of a single string
>
> - I see you are using post-addressing. i.e
>
> /foo/bar/xxx
>
> where we were discussing
>
> /xxx /foo/bar
>
> I prefer the later since it only adds n more paths, whereas the former
> adds n*m more paths.
Yes indeed !