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