charlie hunt wrote:
> On Oct 9, 2009, at 9:20 AM, Jeanfrancois Arcand wrote:
>
>> Salut,
>>
>> Oleksiy Stashok wrote:
>>> Hi,
>>>> (1) Grizzly 2.0 FCS, with a back to back white paper as a
>>>> pre-requisite for release. I sign up for the white paper :-)
>>> Ok :)
>>>>
>>>> (2) Forward port all the http/http-servlet-XX/Comet/OSGi works to
>>>> Grizzly 2.0
>>>>
>>>> ** Anybody interested to contribute I will give committer privileges
>>>> for free :-) **
>>>>
>>>>
>>>> Now I would like to vote on the following topic:
>>>>
>>>> 1. Should the Servlet Container works be only on top of 2.0? Or
>>>> should we make sure both version are supported?
>>> I think it depends on resources we have. Theoretically
>>> ServletContainer will use just high-level HTTP module API, so we will
>>> be able to use the same implementation for both versions.
>>
>> Assuming we keep the (3) -> 1.9.x API.
>
> +1
>
> How does the performance of 2.0 compare to 1.9.x ? Being a performance
> guy that's one of my first questions. :-)
We do have work to do with the current M3 (last time I tested). One goal
is here to have the same performance and if we can gain some %, that
will be an extra :-)
>
> If 2.0 does not perform as well as 1.9.x, then we need to figure out
> what needs to be changed so that it does perform as well, or better. In
> general, I think it is time to move focus towards 2.0.
>
Agree as well.
>>
>>
>>>> 2. Should 1.9.19 be *our last* 1.9.x release with new features, and
>>>> then we move to sustaining mode?
>>> IMO yes.
>>
>> Great!
>
> Agreed.
>
>>
>>>> 3. Should we refactor *entirely* the http module API and make sure
>>>> it is aligned with Grizzly 2.0 new design? I'm tempted to refactor
>>>> everything but we will break a lot of applications
>>> Probably we will need some refactoring to separate HTTP API classes
>>> from HTTP server logic, to make HTTP related classes usable for
>>> server and client sides.
>>
>> Yes this is really something I would like to do. I also want the We
>> Framework to be more Google Guice (and Spring) friendly. We should
>> re-think the GWS API.
>
> What you are suggesting, as painful as it may sound, seems to be a
> natural evolution that we probably should ultimately end up migrating
> towards.
>
>>
>>
>>>> 4. Gitub or Kenai? For sure we MUST move out of java.net
>>> +1
>>> BTW, the bigger concern for me is maven repository. Jave.net maven
>>> repository is very slow and unreliable, do we have better choice?
>>
>> I think we an upload to ibiblio directly.
>>
>>
>>> Glassfish maven repository?
>>
>> That's a solution as well.
>
> I do not have a preference. Just something that's more reliable.
>
>>
>>>> 5. Should we drop Cometd support? Cometd.org can be run using
>>>> Grizzly Comet + Atmosphere
>>> I have no opinion here. If we have Atmosphere as better solution -
>>> then, IMO, there is no reason to keep cometd.
>>
>> We haven't followed the spec closely enough and right now our
>> implementation is out of date. Atmosphere already support the latest
>> Cometd version (1.0.0rc0), and that version runs on top of Grizzly Comet.
>
> I like the idea of going the Atmosphere route. If you can save
> duplication of work and do some consolidation, it seems to make sense to
> go the Atmosphere route as a means to handle cometd.
Exactly. Both Shing Wai and I doesn't have the cycle to maintain the
Cometd implementation up to date. But Atmosphere team has ;-)
A+
-- Jeanfrancois
>
> charlie ...
>
>
>>
>> Thanks
>>
>> -- Jeanfrancois
>>
>>
>>> WBR,
>>> Alexey.
>>>> If you can reply publicly, please reply to jfarcand_at_apache.org with
>>>> your request/recommendation.
>>>>
>>>> Please share your vision :-)
>>>>
>>>> A+
>>>>
>>>> -- Jeanfrancois
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>