Grizzly ROADMAP: 1.9.x and 2.0 -> Time to speak!

[Jeanfrancois Arcand-2]

Salut,

Now that we are *almost* saved from GlassFish work (almost :-)), we will
  eventually have time to come back here and do what we like, which is
to make the community happy and add new features. I would like to start
a new thread discussions about where peoples want to focus on.

Hubert has done great work on the Deployer and Sebastien on annotation
support. What's next? I would propose we work on two things:

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

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

2. Should 1.9.19 be *our last* 1.9.x release with new features, and then
we move to sustaining mode?

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

4. Gitub or Kenai? For sure we MUST move out of java.net

5. Should we drop Cometd support? Cometd.org can be run using Grizzly
Comet + Atmosphere

If you can reply publicly, please reply to jfarcand@... with your
request/recommendation.

Please share your vision :-)

A+

-- Jeanfrancois


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[survivant]

answered inline..

2009/10/8 Jeanfrancois Arcand <Jeanfrancois.Arcand@...>

Salut,

Now that we are *almost* saved from GlassFish work (almost :-)), we will  eventually have time to come back here and do what we like, which is to make the community happy and add new features. I would like to start a new thread discussions about where peoples want to focus on.

Hubert has done great work on the Deployer and Sebastien on annotation support. What's next? I would propose we work on two things:

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

(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 would prefer a clean start.  The team started Grizzly 2.0 from feedback and experience on 1.0, I think it's time to do a fresh start.
 

2. Should 1.9.19 be *our last* 1.9.x release with new features, and then we move to sustaining mode?

I think 1.9.x should be the last.. keep maintaining it, but keep the refactoring or new features for the next point.. See #3
 

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

Again I think we should do it.  Will be easier to add features.  If we keep in mind a target.. like supporting JEE6 :)  it will be possible to refactor/redesign it to support extensions for futures features or embedded API.

We have to open the can anyway to add missing feature to support servlet 2.5.

If we keep maintaining grizzly 1.9x it will become a really stable release and people will have a choice to make for new applications.. G2 ou G1.9.

We should make GF team jealous and of the releases :)

 

4. Gitub or Kenai? For sure we MUST move out of java.net

the easiest to understand.. don't care.
 

5. Should we drop Cometd support? Cometd.org can be run using Grizzly Comet + Atmosphere

I'll pass on that one
 

If you can reply publicly, please reply to jfarcand@... with your request/recommendation.

Please share your vision :-)

 

A+

-- Jeanfrancois


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

--

Vous pouvez me suivre sur Twitter / You can follow me on Twitter : http://twitter.com/survivant

[Oleksiy Stashok]

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@... with  
> your request/recommendation.
>
> Please share your vision :-)
>
> A+
>
> -- Jeanfrancois
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Grey]

On Thu, Oct 8, 2009 at 11:48 AM, Jeanfrancois Arcand <Jeanfrancois.Arcand@...> wrote:

Salut,

...

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 use Grizzly for its exposure of low level APIs and general HTTP support.  Make life easier on yourself and go for just 2.0.
 

2. Should 1.9.19 be *our last* 1.9.x release with new features, and then we move to sustaining mode?

Yes, more focus on 2.0 the better.
 

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

Absolutely.  Why not?.  If 1.9.x is in maintenance, bugs will be fixed, and its pretty solid.  A person could stay on 1.9.x indefinitely.    HTTP is just everywhere and growing.  I use Grizzly primarily as an HTTP engine.   Break eggs, apply that francophone genius of yours to deliver the best HTTP API and engine you can.
 

4. Gitub or Kenai? For sure we MUST move out of java.net

I use Git, and Github.  Love it, can't say enough about. But take this vote as primarily +10 for Git specifically as a great basis for collaborative development in comparison to SVN for example.

 

5. Should we drop Cometd support? Cometd.org can be run using Grizzly Comet + Atmosphere

Not familiar with the how these have been modularized compounded by the fact currently do not have a Comet use-case.  In general, I like flexibility via an exposed, well thought out, cleanly designed, comprehensive API without all fluff.  Not sure if this implies to the above. 

 

If you can reply publicly, please reply to jfarcand@... with your request/recommendation.

Please share your vision :-)

 

Skip 2.0, jump straight to 3.0 - Grizzly written in Scala.    :)  Hey you asked!!! 


Ray

--
The object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane. - Marcus Aurelius

[Jeanfrancois Arcand-2]

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.


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

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


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

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

Thanks

-- Jeanfrancois

>
> WBR,
> Alexey.
>
>
>> If you can reply publicly, please reply to jfarcand@... with
>> your request/recommendation.
>>
>> Please share your vision :-)
>>
>> A+
>>
>> -- Jeanfrancois
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Jeanfrancois Arcand-2]

Salut,

Ray Racine wrote:

> On Thu, Oct 8, 2009 at 11:48 AM, Jeanfrancois Arcand
> <Jeanfrancois.Arcand@... <mailto:Jeanfrancois.Arcand@...>> wrote:
>
>     Salut,
>
> ...
>
>
>     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 use Grizzly for its exposure of low level APIs and general HTTP
> support.  Make life easier on yourself and go for just 2.0.

:-)


>  
>
>
>     2. Should 1.9.19 be *our last* 1.9.x release with new features, and
>     then we move to sustaining mode?
>
>
> Yes, more focus on 2.0 the better.
>  

Agree

>
>
>     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
>
>
> Absolutely.  Why not?.  If 1.9.x is in maintenance, bugs will be fixed,
> and its pretty solid.  A person could stay on 1.9.x indefinitely.    
> HTTP is just everywhere and growing.  I use Grizzly primarily as an HTTP
> engine.   Break eggs, apply that francophone genius of yours to deliver
> the best HTTP API and engine you can.

Thanks!

>  
>
>     4. Gitub or Kenai? For sure we MUST move out of java.net
>     <http://java.net>
>
>
> I use Git, and Github.  Love it, can't say enough about. But take this
> vote as primarily +10 for Git specifically as a great basis for
> collaborative development in comparison to SVN for example.

Ya I also like Git a lot.

>  
>
>     5. Should we drop Cometd support? Cometd.org can be run using
>     Grizzly Comet + Atmosphere
>
> Not familiar with the how these have been modularized compounded by the
> fact currently do not have a Comet use-case.  In general, I like
> flexibility via an exposed, well thought out, cleanly designed,
> comprehensive API without all fluff.  Not sure if this implies to the
> above.

Here we are talking about Cometd...I think we should keep in Grizzly the
APR/Comet API as they are widely used. For Cometd, using the version
from the Cometd.org on top of Atmosphere/Grizzly gives the same experience.

I will start a new thread on Cometd just to make sure every body
saw/follow our decision.

>
>  
>
>     If you can reply publicly, please reply to jfarcand@...
>     <mailto:jfarcand@...> with your request/recommendation.
>
>     Please share your vision :-)
>
>  
> Skip 2.0, jump straight to 3.0 - Grizzly written in Scala.    :)  Hey
> you asked!!!

Hahaha :-) Ya with Atmosphere I've started writing apps in Scala and
agree this is a pretty amazing new things to learn!

Thanks!!

-- Jeanfrancois


>
>
> Ray
>
> --
> The object of life is not to be on the side of the majority, but to
> escape finding oneself in the ranks of the insane. - Marcus Aurelius

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[charlie hunt-3]

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@...  
>>> with your request/recommendation.
>>>
>>> Please share your vision :-)
>>>
>>> A+
>>>
>>> -- Jeanfrancois
>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Justin Lee-3]

Jeanfrancois Arcand wrote:

> Salut,
>
> Now that we are *almost* saved from GlassFish work (almost :-)), we
> will  eventually have time to come back here and do what we like,
> which is to make the community happy and add new features. I would
> like to start a new thread discussions about where peoples want to
> focus on.
>
> Hubert has done great work on the Deployer and Sebastien on annotation
> support. What's next? I would propose we work on two things:
>
> (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 :-)
>
> (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?

2.0 only, I'd think.  Let's focus on "modern" code.  It'll take some
time to get it right, so let's not worry about supporting older versions.
>
> 2. Should 1.9.19 be *our last* 1.9.x release with new features, and
> then we move to sustaining mode?
I'd rather be on 2.0 *now*.  ;)
>
> 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
See #1.  2.0 is already a breaking change as I understand it.  No reason
to stop now.
>
> 4. Gitub or Kenai? For sure we MUST move out of java.net
kenai might be a more politically correct choice.  I've not used github
but I use kenai for several projects and really like it.  I don't know
how the feature sets compare but kenai offers quite a bit.

>
> 5. Should we drop Cometd support? Cometd.org can be run using Grizzly
> Comet + Atmosphere
>
> If you can reply publicly, please reply to jfarcand@... with
> your request/recommendation.
>
> Please share your vision :-)
>
> A+
>
> -- Jeanfrancois
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[doris chen]

See comments/questions below
Jeanfrancois Arcand wrote:

> Salut,
>
> Now that we are *almost* saved from GlassFish work (almost :-)), we
> will  eventually have time to come back here and do what we like,
> which is to make the community happy and add new features. I would
> like to start a new thread discussions about where peoples want to
> focus on.
>
> Hubert has done great work on the Deployer and Sebastien on annotation
> support. What's next? I would propose we work on two things:
>
> (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 :-)
>
> (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?
>
> 2. Should 1.9.19 be *our last* 1.9.x release with new features, and
> then we move to sustaining mode?
>
> 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

It's a tough decision.  Will this refactoring also break all the sample
code (chat, twitter, etc)?  Will it be easy to fix afterwards?
>
> 4. Gitub or Kenai? For sure we MUST move out of java.net
Gitub sounds good me.
>
> 5. Should we drop Cometd support? Cometd.org can be run using Grizzly
> Comet + Atmosphere
Cometd approach attracts a lot of developers (especially for beginners)
to try developing comet application, as it is very easy to get started
with.   If we have a chat application (developed with Dojo cometd
package), can we run it on  Comet+Atmosphere  without any code change?

Thanks,

Doris

>
> If you can reply publicly, please reply to jfarcand@... with
> your request/recommendation.
>
> Please share your vision :-)
>
> A+
>
> -- Jeanfrancois
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Jeanfrancois Arcand-2]

Salut,

doris chen wrote:

> See comments/questions below
> Jeanfrancois Arcand wrote:
>> Salut,
>>
>> Now that we are *almost* saved from GlassFish work (almost :-)), we
>> will  eventually have time to come back here and do what we like,
>> which is to make the community happy and add new features. I would
>> like to start a new thread discussions about where peoples want to
>> focus on.
>>
>> Hubert has done great work on the Deployer and Sebastien on annotation
>> support. What's next? I would propose we work on two things:
>>
>> (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 :-)
>>
>> (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?
>>
>> 2. Should 1.9.19 be *our last* 1.9.x release with new features, and
>> then we move to sustaining mode?
>>
>> 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
> It's a tough decision.  Will this refactoring also break all the sample
> code (chat, twitter, etc)?  Will it be easy to fix afterwards?

It really depend on what we will change. But yes it may break all of
those. But the idea here will be to release only when all the samples
are back to work normally.

>>
>> 4. Gitub or Kenai? For sure we MUST move out of java.net
> Gitub sounds good me.
>>
>> 5. Should we drop Cometd support? Cometd.org can be run using Grizzly
>> Comet + Atmosphere
> Cometd approach attracts a lot of developers (especially for beginners)
> to try developing comet application, as it is very easy to get started
> with.   If we have a chat application (developed with Dojo cometd
> package), can we run it on  Comet+Atmosphere  without any code change?

Yes. The Atmosphere Bayeux Plug In allow you to run the official
Cometd.org implementation on top of any Web Server, including Grizzly.
GlassFish v3 will also ship with Atmosphere Bayeux.

Thanks!

-- Jeanfrancois

> Thanks,
>
> Doris
>>
>> If you can reply publicly, please reply to jfarcand@... with
>> your request/recommendation.
>>
>> Please share your vision :-)
>>
>> A+
>>
>> -- Jeanfrancois
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Jeanfrancois Arcand-2]

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@... with
>>>> your request/recommendation.
>>>>
>>>> Please share your vision :-)
>>>>
>>>> A+
>>>>
>>>> -- Jeanfrancois
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>> For additional commands, e-mail: users-help@...
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Igor Minar]

On Oct 8, 2009, at 8:48 AM, Jeanfrancois Arcand wrote:

> Salut,
>
> Now that we are *almost* saved from GlassFish work (almost :-)), we  
> will  eventually have time to come back here and do what we like,  
> which is to make the community happy and add new features. I would  
> like to start a new thread discussions about where peoples want to  
> focus on.
>
> Hubert has done great work on the Deployer and Sebastien on  
> annotation support. What's next? I would propose we work on two  
> things:
>
> (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 :-)
>
> (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?

yes

>
> 2. Should 1.9.19 be *our last* 1.9.x release with new features, and  
> then we move to sustaining mode?

yes, except for bugfixing and important glassfish related work

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

yes! the http api isn't very pretty and easy to use.

>
> 4. Gitub or Kenai? For sure we MUST move out of java.net

anything is better than the current situation. Though I still think  
that mercurial is easier to use than git, but otherwise both have very  
similar features.

>
> 5. Should we drop Cometd support? Cometd.org can be run using  
> Grizzly Comet + Atmosphere
>
> If you can reply publicly, please reply to jfarcand@... with  
> your request/recommendation.

I'd like to see more focus on having cleaner API, more documentation  
and making the test suite run faster (e.g. by parallelizing the tests).

cheers,
Igor

>
> Please share your vision :-)
>
> A+
>
> -- Jeanfrancois
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Hubert Iwaniuk]

Hi,

On Thu, Oct 8, 2009 at 5:48 PM, Jeanfrancois Arcand <Jeanfrancois.Arcand@...> wrote:

Salut,

Now that we are *almost* saved from GlassFish work (almost :-)), we will  eventually have time to come back here and do what we like, which is to make the community happy and add new features. I would like to start a new thread discussions about where peoples want to focus on.

Hubert has done great work on the Deployer and Sebastien on annotation support. What's next? I would propose we work on two things:

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

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

As work on Servlet Container was done on 1.9.x we have it supported for free.

+1 both versions, as long as its not getting to hard to keep 1.9.x version.

 

2. Should 1.9.19 be *our last* 1.9.x release with new features, and then we move to sustaining mode?

+1 lets move forward

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

+1 refactor

I like what Alexey said. Refactor at least to point where we can separate HTTP API from HTTP Server code.

Yes I'm looking here at HTTP Client and Proxy.

4. Gitub or Kenai? For sure we MUST move out of java.net

+1 github, as long as we are talking only about moving sources.

5. Should we drop Cometd support? Cometd.org can be run using Grizzly Comet + Atmosphere

+1 drop

 

If you can reply publicly, please reply to jfarcand@... with your request/recommendation.

Please share your vision :-)

A+

-- Jeanfrancois


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[ming qin]

Some parts of this message have been removed. Learn more about Nabble's security policy.

 

Goals of Grizzly 2.x new design and implementations ---Making grizzly users happy by adding new features

 

I recommend  that new Girzzly 2.x  with added features or API code refactoring should be backward compatible – at least not to upset glassfish and jetty in sense of performance and usability of API.

From what I observed, Grizzly users consists of two kinds of users.

The first ones are current grizzly adaptors such as glassfish –j2ee application server, jetty- http server and servlet container, and tryout  ( Bayeux , comet, HttpService OSGI)

The second ones are potential grizzly users such as socket server for online games, audio and video streaming server, peer-to-peer file sharing application, or cloud computing application.

The new version of Grizzly should be attractive enough to convince current grizzly adaptors to eagerly spend time and energy to migrate to new grizzly version. Meanwhile, those potential grizzly users will realize Grizzly is a speedway for them to take advantages offered by multiplexed I/O( readiness selection)  and nonblocking I/O.

With good mouth of current grizzly adaptors and more institutive, well-documented and more test case-richen  grizzly,  grizzly can reach new height of maturity and acceptance by converting more potential users to grizzly adaptors.  

Ming Qin
Cell Phone [phone]

-

[Matthew Swift]

Hi,

As new users of Grizzly and having had no experience of previous
releases, I thought I'd share our initial impressions and
recommendations for 2.0. I don't know how much they make sense because
our experience is pretty restricted to using Grizzly as a pure IO
framework, and we don't have much interest in the Web related related
functionality (e.g. HTTP / Comet) at the moment.

So here goes: our first impression is that it's very easy to get lost in
the APIs and not know where to start (this may be a direct result of the
documentation being currently aligned on 1.9.x releases?). There seem to
be some key classes buried down in sub-packages and also overlapping
functionality (e.g. codecs vs filters). Another thing that bugs me is
that everything is public which adds to the confusion. Therefore I think
that some time should be spent on the following:

    * Update/finish Javadoc and update documentation on website.

    * Make an effort to hide as much implementation detail as possible:
      only expose classes / methods / fields which are intended for
      public consumption. Make classes/methods final where possible and
      document things that are intended for extension. All basic Joshua
      Bloch stuff really. :-)

    * All aspects of performance and scalability are absolutely critical
      for us, but we are not yet at a point where we can provide useful
      feedback (our Grizzly based prototype is not complete yet). Our
      initial impressions are good though :-)


Regarding Github vs Kenai and (and SVN vs other VCS). Being Java.net
based ourselves we understand the pain you are experiencing! :-( Before
migrating away I would consider the following:

    * Where do you plan to put the website content, mailing lists, WIKI,
      and bug tracking? I don't think Github provides support for any of
      these from a first glance, although I could be completely wrong.

    * User migration / authentication: I wouldn't be surprised if
      Project Kenai provides a migration path for users from java.net.
      It's probably worth checking.

    * SVN vs Git vs Hg, etc: personally I would stick with SVN as it's
      fine for most needs, is easy to use, and has very good IDE support
      in Netbeans, Eclipse, and IntelliJ. Our experience of using SVN
      and Hg internally is that there is no noticeable performance
      difference (probably the same applies for Git but I'm just
      guessing) - the reason SVN is slow for us is more to do with
      Java.net than anything else. So I suggest changing provider first
      before changing VCS.

Matt

---

OpenDS Project: http://www.opends.org






On 10/08/2009 05:48 PM, Jeanfrancois Arcand wrote:

> Salut,
>
> Now that we are *almost* saved from GlassFish work (almost :-)), we
> will  eventually have time to come back here and do what we like,
> which is to make the community happy and add new features. I would
> like to start a new thread discussions about where peoples want to
> focus on.
>
> Hubert has done great work on the Deployer and Sebastien on annotation
> support. What's next? I would propose we work on two things:
>
> (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 :-)
>
> (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?
>
> 2. Should 1.9.19 be *our last* 1.9.x release with new features, and
> then we move to sustaining mode?
>
> 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
>
> 4. Gitub or Kenai? For sure we MUST move out of java.net
>
> 5. Should we drop Cometd support? Cometd.org can be run using Grizzly
> Comet + Atmosphere
>
> If you can reply publicly, please reply to jfarcand@... with
> your request/recommendation.
>
> Please share your vision :-)
>
> A+
>
> -- Jeanfrancois
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Jeanfrancois Arcand-2]

Salut,

Matthew Swift wrote:
> Hi,

Apology for the delay

>
> As new users of Grizzly and having had no experience of previous
> releases, I thought I'd share our initial impressions and
> recommendations for 2.0. I don't know how much they make sense because
> our experience is pretty restricted to using Grizzly as a pure IO
> framework, and we don't have much interest in the Web related related
> functionality (e.g. HTTP / Comet) at the moment.
>
> So here goes: our first impression is that it's very easy to get lost in
> the APIs and not know where to start (this may be a direct result of the
> documentation being currently aligned on 1.9.x releases?). There seem to
> be some key classes buried down in sub-packages and also overlapping
> functionality (e.g. codecs vs filters).

Honestly I haven't yet started working on 2.0, letting Alexey driving
it. I will for sure pay attention to the above comment when I start.

For sure I want a back to back white paper included in that release. We
never did it for grizzly 1.9.x and it was a big mistake. The growing
popularity of Netty is an indication that great API + Full documentation
is mandatory.

Another thing that bugs me is
> that everything is public which adds to the confusion. Therefore I think
> that some time should be spent on the following:
>
>    * Update/finish Javadoc and update documentation on website.

Agree

>
>    * Make an effort to hide as much implementation detail as possible:
>      only expose classes / methods / fields which are intended for
>      public consumption. Make classes/methods final where possible and
>      document things that are intended for extension. All basic Joshua
>      Bloch stuff really. :-)

:-)


>
>    * All aspects of performance and scalability are absolutely critical
>      for us, but we are not yet at a point where we can provide useful
>      feedback (our Grizzly based prototype is not complete yet). Our
>      initial impressions are good though :-)

For sure we will do the usual stress test we did for 1.0 and 1.5 when we
started. We have an entire performance team that track us closely.

>
>
> Regarding Github vs Kenai and (and SVN vs other VCS). Being Java.net
> based ourselves we understand the pain you are experiencing! :-( Before
> migrating away I would consider the following:
>
>    * Where do you plan to put the website content, mailing lists, WIKI,
>      and bug tracking? I don't think Github provides support for any of
>      these from a first glance, although I could be completely wrong.
>
>    * User migration / authentication: I wouldn't be surprised if
>      Project Kenai provides a migration path for users from java.net.
>      It's probably worth checking.

Ha I didn't know that one. Good reason.


>
>    * SVN vs Git vs Hg, etc: personally I would stick with SVN as it's
>      fine for most needs, is easy to use, and has very good IDE support
>      in Netbeans, Eclipse, and IntelliJ. Our experience of using SVN
>      and Hg internally is that there is no noticeable performance
>      difference (probably the same applies for Git but I'm just
>      guessing) - the reason SVN is slow for us is more to do with
>      Java.net than anything else. So I suggest changing provider first
>      before changing VCS.

Agree, except SVN merge are my nightmare :-) That's probably the only
reason (valid for me).

Thanks!!!

-- Jeanfrancois

>
> Matt
>
> ---
>
> OpenDS Project: http://www.opends.org
>
>
>
>
>
>
> On 10/08/2009 05:48 PM, Jeanfrancois Arcand wrote:
>> Salut,
>>
>> Now that we are *almost* saved from GlassFish work (almost :-)), we
>> will  eventually have time to come back here and do what we like,
>> which is to make the community happy and add new features. I would
>> like to start a new thread discussions about where peoples want to
>> focus on.
>>
>> Hubert has done great work on the Deployer and Sebastien on annotation
>> support. What's next? I would propose we work on two things:
>>
>> (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 :-)
>>
>> (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?
>>
>> 2. Should 1.9.19 be *our last* 1.9.x release with new features, and
>> then we move to sustaining mode?
>>
>> 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
>>
>> 4. Gitub or Kenai? For sure we MUST move out of java.net
>>
>> 5. Should we drop Cometd support? Cometd.org can be run using Grizzly
>> Comet + Atmosphere
>>
>> If you can reply publicly, please reply to jfarcand@... with
>> your request/recommendation.
>>
>> Please share your vision :-)
>>
>> A+
>>
>> -- Jeanfrancois
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...