[Result] [VOTE] New URI Handling Proposal

[EP...@upstate.com]

I think that there have been enough +1's to go ahead with Henning's new URI
code and deprecate the old stuff for 2.3.

Voting +1 where:
Scott Eade
Martin Poeschl
Quinton McCombs
Henning P. Schmiedehausen
Eric Pugh

Voting -1 where:
nobody!

Henning, do you want to go ahead and make the changes to the Turbine 2.3
codebase?  Would you be willing to add the contents of your Readme into the
Wiki page for 2.2 -> 2.3 migration?

I think it is time to think about cutting 2.3 beta 1.

Eric Pugh



-----Original Message-----
From: Scott Eade [mailto:seade@backstagetech.com.au]
Sent: Wednesday, April 23, 2003 8:25 AM
To: turbine-dev
Subject: Re: [VOTE] New URI Handling Proposal


+1

On 23/04/2003 2:22 AM, "EPugh@upstate.com" <EP...@upstate.com> wrote:

> Hi all,
> 
> Henning has come up with a new URI handling proposal.  I have tried out
his
> code in two big projects and have found this code to be backwards
compatible
> once I updated my TR.props.
> 
> For a readme:
>
http://cvs.apache.org/viewcvs/jakarta-turbine-2/proposals/henning/new-uri/RE
> ADME?rev=1.2&content-type=text/vnd.viewcvs-markup
> 
> For an explanation behind the changes from an earlier email:
> 
> <snip>
> Mainly I wanted to cleanly separate the Tool(s) from the internal
> classes.  All methods either return values / void (classes for Java
> code) or the tool class (stuff in pull.tools) which is for usage in
> Velocity templates.
> 
> There is now a class hierarchy in terms of functionality which removes
> all duplicated code and you can construct the various URI classes not
> only from RunData but also from ServerData object, which are more
> often available once you go outside tool scope.
> 
> Also, all of the URI/Link classes provide both, "Absolute" and a
> "Relative" path conversion (where the old code provided the "Relative"
> just as an afterthought.
> 
> I did rewrite this because at some point, I spent more time, chasing
> bugs and "strange stuff" in the URI classes than actually writing code
> of my application. As I told numerous times, I don't like cookie
> session tracking, so I try to go with "jsessionid=" everywhere and the
> old URI stuff simply had numerous bugs with this.
> 
> And after looking into the whole URI code a little deeper I found that
> lots of this code was duplicated in various classes with some bug
> fixes applied to DynamicURI, some other to the Link classes, some code
> with same functionality was written in numerous different ways and so
> on. Just some sort of "hey, lets hack something in here, because I
> need exactly this". The sort of code that I don't like. :-)
> </snip>
> 
> If you have already voted, don't worry about voting again.  I just wanted
to
> get a formal email out that is easier to search on!
> 
> Here is my +1.  Eric Pugh
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org

Re: [Result] [VOTE] New URI Handling Proposal

["Henning P. Schmiedehausen" <hp...@intermeta.de>]

EPugh@upstate.com writes:

>Henning, do you want to go ahead and make the changes to the Turbine 2.3
>codebase?  Would you be willing to add the contents of your Readme into the
>Wiki page for 2.2 -> 2.3 migration?

Ok, I will. If anyone else (you) can add this stuff to the Wiki I
would be grateful, mainly I might be the last human being on earth
that does not know how to handle a wiki... :-)

>I think it is time to think about cutting 2.3 beta 1.

Skipping "alpha"? Or how about going Linux-Style? 2.3pre1, 2.3pre2,
2.3rc1, 2.3

I do have to add much stuff to the changes.xml, though.

	Regards
		Henning
-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen          INTERMETA GmbH
hps@intermeta.de        +49 9131 50 654 0   http://www.intermeta.de/

Java, perl, Solaris, Linux, xSP Consulting, Web Services 
freelance consultant -- Jakarta Turbine Development  -- hero for hire

---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org