[OSC_dev] oscit registration complete !

[Gaspard Bucher]

On Tue, Jan 13, 2009 at 10:33 AM,  <salsaman at xs4all.nl> wrote:
> 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.
>
Yes, I agree.
>
>> 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.

I am used to huge refactorings so I'm not afraid to rewrite things
(that's the main point in agile development).

>
> Cheers,
> Gabriel.
> http://lives.sourceforge.net
>
>
> _______________________________________________
> OSC_dev mailing list
> OSC_dev at create.ucsb.edu
> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev
>