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