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. :-)
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.
>
>
>>> 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.
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
>