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.
> 2. Should 1.9.19 be *our last* 1.9.x release with new features, and
> then we move to sustaining mode?
IMO yes.
> 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.
> 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?
Glassfish maven repository?
> 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.
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
>