[OSC_dev] oscit registration complete !

[Gaspard Bucher]

Some of the things that were (sort of) agreed like accessors are
rolled back to set/get on omc wetpaint. I think we have slightly
different goals with this protocol. You need scripting, I need
hardware controls and remote UI. I think it's ok if we try our ideas
with our different needs and then see how it goes.

On Mon, Jan 12, 2009 at 11:21 PM,  <salsaman at xs4all.nl> wrote:
> On Mon, January 12, 2009 17:36, Gaspard Bucher wrote:
>> On Mon, Jan 12, 2009 at 3:11 PM,  <salsaman at xs4all.nl> wrote:
>>> On Sun, January 11, 2009 21:49, Gaspard Bucher wrote:
>>>> I am glad to announce that "oscit" is now a registered dns-sd service
>>>> type:
>>>>
>>>> http://www.dns-sd.org/ServiceTypes.html
>>>>
>>>> For those of you not familiar with dns-sd (service discovery), this is
>>>> what helps us use printers out of the box without configuring their
>>>> network interface or our machines.
>>>>
>>>> The library is advancing at a good pace. I'll keep you informed.
>>>>
>>>> Gaspard
>>>> _______________________________________________
>>>> OSC_dev mailing list
>>>> OSC_dev at create.ucsb.edu
>>>> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev
>>>>
>>>
>>>
>>> I think also we should try to resolve the points of contention before
>>> you
>>> put it up as "official" at http://rubyk.org/en/oscit
>>>
>>> Second please don't start introducing your own ideas without discussing
>>> them (e.g. replies starting with /.reply).
>>>
>>>
>>> It seems to me that you have taken the original idea (come up with a
>>> joint
>>> standard), and run off with your own version (oscit) with minimal
>>> discussion, registered it as an official standard and are now starting
>>> to
>>> implement it. I can understand your enthusiasm, but I suspect that if
>>> you
>>> continue like this then your application will be the only one using
>>> oscit.
>>> Thats fine if you are in a hurry, but then you should be prepared to
>>> come
>>> back and change things later. The standard is not ready until all of the
>>> participants are agreed on all of the points.
>>>
>>> Regards,
>>> Gabriel.
>>> http://lives.sourceforge.net
>>>
>>>
>> Hey ! No harm. Everything listed on the oscit page has been discussed
>> on this mailing list (the /.reply was discussed here:
>> http://www.nabble.com/Fwd%3A--Application-Profiles%3A-oscplanet-td21130644.html)
>> and it's clearly a draft (written in big blue letters).
>>
>
> Sure, it was discussed briefly on the mailing list, but I don't think any
> agreement was reached.
>
>
>> I want to make sure this protocol works and is rock solid so I decided
>> to start the implementation and test the ideas that have been (sort
>> of) agreed so far. Once we have something implemented and working, we
>> can discuss what needs to be changed. I just don't what to wait for a
>> total agreement on everything to start working since I don't think we
>> can settle on something good without testing our ideas. The need for
>> "/.reply" for example comes from a real world situation.
>>
>
> Well, for me as it is it does not and cannot work. I have explained that I
> need /get and /set, even if I follow the suggestions others have made /get
> and /set are required for me to be able to recognise the difference
> between a property and a command.
>
> /.reply_to should be without a dot, because it is just a command, not a
> meta command. I think the distinction should be kept clear.
>
> And also, I am totally opposed to having to send replies in OSC format,
> doubly so for having to prefix /.reply on the beginning. If you need to do
> that, the surely the receiving application can reformat the reply
> internally.
>
>
>> Another example is the "/.reply_to": it could be dropped altogether
>> because the querying application could register itself as a target for
>> replies and it would automatically get them without needing any
>> "state" recorded in the server side. But this has to be tested.
>>
>
> Register itself how ? The scripts I use to connect to LiVES are very
> simple, I don't want to add any additional complication to them.
>
> /reply_to localhost 9998
>
> works just fine.

Well, that's an argument to keep it (simple scripts without dns-sd
support). As for the "." before "reply_to" I think it is needed so
that none of oscit methods clutter the normal osc tree.

All in all, I'm a little amazed at the reactions for the "oscit"
registration. What's the harm of having a protocol that is:

1. easy to implement (simple library provided)
2. plug & play (configuration free zeroconf)
3. embeddable (easy to use for hardware vendors)

As I said, I need to move on: I have been working on this protocol
idea from June 2008 (request for funding) and the thing was due in
october.

Gaspard