Re: [vote] Let our environment abtractions extend the http servlet ones

[Alfred Nathaniel <an...@apache.org>]

On Tue, 2007-08-07 at 09:46 +0200, Daniel Fagerstrom wrote:
> Unfortunately it is more complicated than that. The non-compatible 
> change is that Request.getSession switches return value from 
> o.a.c.environment.Session to javax.servlet.http.HttpSession and that 
> Request.getCookie switch return value from o.a.c.environment.Cookie to 
> javax.servlet.http.Cookie. You, of course, cannot have a method with two 
> different return types. So there is no point in deprecating 
> Request.getSession and Request.getCookie in 2.2 as we not will have any 
> replacements until 2.3 in that case. So the deprecation mechanism is 
> AFAICS not applicable.

How about this:

1.) In 2.1.11 add Request.getCocoonSession and Request.getCocoonCookie
and deprecate the current methods.

2.) In 2.2 let o.a.c.e.XXX extend the standard interfaces, change return
types of getXXX methods and deprecate getCocoonXXX methods.

3.) In 2.3 remove getCocoonXXX and o.a.c.e.XXX.

That allows for a smoother transition path for user components because
they can be made forwards compatible to work for both 2.1.11+ and 2.2
(if Session/Cookie is the only incompatibility?).

In any case, I am -1 on creating a 2.3 branch in the near future.  First
we must get out 2.2 and let it season on trunk to reach production
quality.  The parallel maintenance and forward and backward porting
between 2.1 and 2.2 was a terrible resource drain which we should try to
avoid as far as possible.

Cheers, Alfred.

Re: [vote] Let our environment abtractions extend the http servlet ones

[Vadim Gritsenko <va...@reverycodes.com>]

Alfred Nathaniel wrote:
> On Tue, 2007-08-07 at 09:46 +0200, Daniel Fagerstrom wrote:
>> Unfortunately it is more complicated than that. The non-compatible 
>> change is that Request.getSession switches return value from 
>> o.a.c.environment.Session to javax.servlet.http.HttpSession and that 
>> Request.getCookie switch return value from o.a.c.environment.Cookie to 
>> javax.servlet.http.Cookie. You, of course, cannot have a method with two 
>> different return types. So there is no point in deprecating 
>> Request.getSession and Request.getCookie in 2.2 as we not will have any 
>> replacements until 2.3 in that case. So the deprecation mechanism is 
>> AFAICS not applicable.
> 
> How about this:
> 
> 1.) In 2.1.11 add Request.getCocoonSession and Request.getCocoonCookie
> and deprecate the current methods.
> 
> 2.) In 2.2 let o.a.c.e.XXX extend the standard interfaces, change return
> types of getXXX methods and deprecate getCocoonXXX methods.
> 
> 3.) In 2.3 remove getCocoonXXX and o.a.c.e.XXX.
> 
> That allows for a smoother transition path for user components because
> they can be made forwards compatible to work for both 2.1.11+ and 2.2
> (if Session/Cookie is the only incompatibility?).
> 
> In any case, I am -1 on creating a 2.3 branch in the near future.  First
> we must get out 2.2 and let it season on trunk to reach production
> quality.  The parallel maintenance and forward and backward porting
> between 2.1 and 2.2 was a terrible resource drain which we should try to
> avoid as far as possible.

+1

Vadim

Re: [vote] Let our environment abtractions extend the http servlet ones

[Daniel Fagerstrom <da...@nada.kth.se>]

Alfred Nathaniel skrev:
> On Tue, 2007-08-07 at 09:46 +0200, Daniel Fagerstrom wrote:
>   
>> Unfortunately it is more complicated than that. The non-compatible 
>> change is that Request.getSession switches return value from 
>> o.a.c.environment.Session to javax.servlet.http.HttpSession and that 
>> Request.getCookie switch return value from o.a.c.environment.Cookie to 
>> javax.servlet.http.Cookie. You, of course, cannot have a method with two 
>> different return types. So there is no point in deprecating 
>> Request.getSession and Request.getCookie in 2.2 as we not will have any 
>> replacements until 2.3 in that case. So the deprecation mechanism is 
>> AFAICS not applicable.
>>     
>
> How about this:
>
> 1.) In 2.1.11 add Request.getCocoonSession and Request.getCocoonCookie
> and deprecate the current methods.
>
> 2.) In 2.2 let o.a.c.e.XXX extend the standard interfaces, change return
> types of getXXX methods and deprecate getCocoonXXX methods.
>   
Seem like a good suggestion to me. It will give users that going the 
path of first upgrading to 2.1.11 and then to 2.2 a smooth path and the 
appropriate deprecation warnings when  they build their own code. It is 
important that we document what we are up to well in 2.1.11 so that 
users understand what is going on and where it is leading.
> 3.) In 2.3 remove getCocoonXXX and o.a.c.e.XXX.
>   
Removing o.a.c.e.XXX is a little bit more complicated as the Request 
interface has a few methods for handling sub sitemap paths. But maybe we 
could introduce a minimal interface for just those methods and deprecate 
o.a.c.e.XXX. Anyway, from our current speed in switching minor version, 
we might not be in such a hurry in deciding the exact details of 2.3 ;)
> That allows for a smoother transition path for user components because
> they can be made forwards compatible to work for both 2.1.11+ and 2.2
> (if Session/Cookie is the only incompatibility?).
>   
Yes, AFAICS, I tried the changes locally to be able to see the consequences.
> In any case, I am -1 on creating a 2.3 branch in the near future.  First
> we must get out 2.2 and let it season on trunk to reach production
> quality.  The parallel maintenance and forward and backward porting
> between 2.1 and 2.2 was a terrible resource drain which we should try to
> avoid as far as possible.
>   
Agree, I'll be -1 on branches as well.

/Daniel