I didn't follow this thread.. but look like some people need vacations :) (
I do :))
2010/1/12 gustav trede <gustav.trede_at_gmail.com>
>
> Im done here for good at last. its not about this specific issue at all. I
> see no future here. sorry.
>
>
> 2010/1/12 Justin Lee <Justin.Lee_at_sun.com>
>
>> um. wow. ok.
>>
>> No one said anything about your websocket stuff being unviable. Merely
>> that the first approach we're trying to integrate that (and *other* I might
>> add) suggestions might not be the best approach. Try calming down and work
>> with us through the issues and try not to speculate on things you don't know
>> about. It'll all work out in the end.
>>
>>
>> On 1/12/10 4:34 PM, gustav trede wrote:
>>
>>> I will never work with 2.0. I disagree with its design.
>>> Its of interest that JFA dont like it either, wonder why he left anyhow ?
>>> He stated two times to me last year that 2.0 is "slow". last time was in
>>> december.
>>>
>>> Its ok that my hack for websocket integration is not viable, its sun
>>> management that ask for websocket, not me. im not intereted now.
>>> I can work for free at other projects that might have a more economical
>>> future.
>>> Its too unclear what oracle will do for me to spend any further time atm.
>>>
>>> 2010/1/12 Justin Lee<Justin.Lee_at_sun.com>
>>>
>>>
>>>
>>>> The current approach alexey and I have been talking about is to allow
>>>> more
>>>> than one Interceptor on a task. This causes all sorts of cascading and
>>>> breaking changes on the StreamAlgorithm classes, e.g., which are
>>>> deprecated
>>>> in favor of the port unification classes favored by 2.0.
>>>>
>>>>
>>>> On 1/12/10 4:23 PM, gustav trede wrote:
>>>>
>>>>
>>>>
>>>>> 2010/1/12 Justin Lee<Justin.Lee_at_sun.com>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> I'm not sure this should be fixed by adding support for mulitple
>>>>>> interceptors (on a ProcessorTask, e.g.). Most of the changes so far
>>>>>> involve
>>>>>> altering deprecated classes which is a little contradictory. In 2.x,
>>>>>> the
>>>>>> planned approach would be to use the port-unification/ProtocolFilter
>>>>>> approach and I think we should do that for 1.9.x as well. It's a
>>>>>> much,
>>>>>> much
>>>>>> clean approach and could be done with relatively little change to
>>>>>> existing
>>>>>> code. It'd just be another PF in the chain that would halt any
>>>>>> further
>>>>>> execution of the chain. So it'd be the same basic logic as the
>>>>>> current
>>>>>> suggested approach without all the ugly hackery going on to retrofit
>>>>>> this
>>>>>> update in a non-breaking fashion. As it is now, it's looking more and
>>>>>> more
>>>>>> like a breaking API change on the 1.9.x tree and that's something
>>>>>> we're
>>>>>> striving to avoid. Thoughts?
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>>>>>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> The current impl in trunk dont break any API.
>>>>> Can you provide a working example of what your proposing, for example
>>>>> how
>>>>> websocket is to use it?.
>>>>> The existing code is in processortask in trunk.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>>>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>
>>
>
>
> --
> regards
> gustav trede
>
>
>
--
-------------
A+
Sébastien.
Vous pouvez me suivre sur Twitter / You can follow me on Twitter :
http://twitter.com/survivant