[OSC_dev] oscit registration complete !

[salsaman at xs4all.nl]

On Tue, January 13, 2009 09:22, Gaspard Bucher wrote:
> 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.


I disagree. I think it is fine for oscit to include both standard methods
and meta-methods. Then depending on the (sub) namespaces supported, the
standard methods list increases.



>
> 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)
>

There is no harm in it, it's a great idea ! BUT in order for it to work,
it must address the needs/requirements of all of the participants. If
there is a conflict between the needs of different users, then a solution
needs to be designed which is flexible enough to fit the needs of all.


> 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

Sure, I understand, we all have deadlines and budgets. Unfortunately this
means that we might have to implement now, and come back in the future and
make some adjustments.

Hopefully those adjustments are minor.

Cheers,
Gabriel.
http://lives.sourceforge.net