You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by "Craig R. McClanahan" <cr...@apache.org> on 2004/01/22 10:10:43 UTC
RE: [codec] More thoughts on CharSets and Encoders (references: R E: [codec] Streamable Codec Framework)
Quoting Gary Gregory <gg...@seagullsw.com>:
> (1) "eventually" is, sadly I think, a ways off in the future. See
> discussions on this list WRT J2ee containers, WebSphere, most common
> installed base of such containers, etc.
>
<personal-viewpoint author="craigmcc">
As a major proponent of long-term support for existing packages that want to do
evolutionary development, this is an important issue. My own experience with
Struts (which still supports Servlet 2.2 / JSP 1.1) says that this is important
for existing users. And it will continue to be. *Nobody* in the real world
can migrate to more current technologies as fast as the developers of those
technologies would wish that they could.
However, I get really impatient with this reality for *future* users.
Many/most
Jakarta projects tend to focus on the "what is widely deployed now" scenario --
but limiting ongoing development to this kind of platform is *very* bad for the
Java platform in the long run.
Personally, I will continue to invest effort in supporting existing users of
the
Apache/Jakarta packages I contribute to. But my primary focus for future
efforts are going to be focused on leveraging the platforms that are more
current in the mainstream ... with the expectation that folks on platforms that
don't have this current support *will* be taken care of by the time that the
revolutionary software is (if it ever is) ready for general release.
As such, I'm personally not interested in working on any revolutionary Struts
or
Commons designs that do not presume at least J2SE 1.4 / J2EE 1.4 as the base
platform as the minimum requirement. That's not to say that the needs of
exisiting pre-1.4-based users, or non-mainstream platforms that don't support
SE/EE 1.4, aren't important --- nothing could be further from the truth! -- but
limiting the ongoing development of Jakarta-based software (overall, the
convention seems to be to support JDK 1.2 as the minimum platform with some
packages supporting 1.1 compatible versions) is going to be very detrimental to
the long-term success of the Java platform.
The JDK 1.2 environment was *years* ago ... when a 256mHz PC was the tip of the
state of the art. Would you willing to accept being required to work on such a
hardware system today?
It's time for us to recognize that there are *millions* of mainstream users,
who
*can* provide a 1.4 baseline runtime environmment -- and, as a whole, the
Jakarta community is not paying enough attention to what kinds of capabilities
can not be assumed. Lets *stop* limiting our revolutionary advances by an
assumption that we have to be backwards compatible with what (in computer
terms) is now considered the Iron Age of computing.
</personal-viewpoint>
Craig McClanahan
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [codec] More thoughts on CharSets and Encoders (references: R E: [codec] Streamable Codec Framework)
Posted by "Craig R. McClanahan" <cr...@apache.org>.
Quoting Oleg Kalnichevski <ol...@bluewin.ch>:
> > The most important phrase in Craig's email was: "As such, I'm
> > personally not interested in working on any revolutionary Struts or
> > Commons designs that do not presume at least J2SE 1.4 / J2EE 1.4 as the
> > base platform as the minimum requirement."
>
> Tim & Craig,
>
> I wish I could agree with you,
Not really asking you to, since it was an expression of where *I* am going to
focus my own personal efforts :-).
> but unfortunately I have to say that this
> is a very PC- (or let me say big-time computing) centric point of view.
> There are still enough platforms that are in a widespread use where even
> Java 1.2 is not available, for instance MacOS 9 and, more importantly,
> all sorts of micro devices and embedded systems. True, it does not make
> sense to run Struts on a PDA or on a mobile phone. However,
> commons-codec being a low level library may come quite handy when
> developing applications for PDAs. Same story goes for HttpClient, which
> has recently become dependent on commons-codec. HttpClient in its turn
> is a dependency for XML-RPM. Making Codec require Java 1.4 (at this
> point) will cause a rippling effect on many other projects which are
> dependent (either directly or indirectly) on this library.
>
> IMHO, Commons-Codec as well as Commons HttpClient being low level
> libraries should target as wider user base as possible. Funny enough, we
> (HttpClient) still get requests for Java 1.1.8 compatibility once in a
> while. Some people went ever as far as creating a semi-official Java
> 1.1.8 fork to cater to their specific needs. The last thing I would like
> to see is a Java 1.2.x fork in addition to that.
>
> I am not saying Codec should not go forward and adopt new features in
> the Java platform that sense for it. However, we should consider not
> only the risk of working ourselves out of existence but also the risk of
> ending up working just for ourselves.
>
> At the very least I would like to see a more coherent policy towards
> Java platform compatibility across all Commons sub-project. I believe
> there must be a common baseline we should all agree upon and then stick
> to, whatever it is.
>
It's up to the developers of each package. The best way to influence that
decision, for the packages that people care about, is to become a developer on
them :-).
Most appear to have settled on 1.2 as a base platform, with some still trying to
make provisions for 1.1. But this decision has negative consquences for
Jakarta packages as well -- it means we tend to spend a lot of time
re-inventing what is already available, and we tend to not even think about
designs that are enabled by the newer JDK's features, simply because it would
take lots of work to write corresponding support for pre-1.4 users. Over the
last couple of years, the net result of this (across all the Jakarta projects
I'm familiar with) is a gradual reduction in innovation and new ideas.
I'm not a codec contributor, so I don't have a voice in the decision for that
package. I agree with your point that the use cases are likely to be
different. Also, one could jusifiably accuse me of hijacking this message
thread :-)
But I really would like to see Jakarta projects do things for all the 1.4 users
in the world, even if it means that code won't be helping users on pre-1.4
systems. And, since my primary interest is on server side apps (where 1.4 is
more commonly available, or will be very soon), that's where I'm going to
focus.
> Cheers,
>
> Oleg
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [codec] More thoughts on CharSets and Encoders (references: R
E: [codec] Streamable Codec Framework)
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Oleg Kalnichevski wrote:
>>The most important phrase in Craig's email was: "As such, I'm
>>personally not interested in working on any revolutionary Struts or
>>Commons designs that do not presume at least J2SE 1.4 / J2EE 1.4 as the
>>base platform as the minimum requirement."
>
>
> Tim & Craig,
>
> I wish I could agree with you, but unfortunately I have to say that this
> is a very PC- (or let me say big-time computing) centric point of view.
> There are still enough platforms that are in a widespread use where even
> Java 1.2 is not available, for instance MacOS 9 and, more importantly,
> all sorts of micro devices and embedded systems. True, it does not make
> sense to run Struts on a PDA or on a mobile phone. However,
> commons-codec being a low level library may come quite handy when
> developing applications for PDAs. Same story goes for HttpClient, which
> has recently become dependent on commons-codec. HttpClient in its turn
> is a dependency for XML-RPM. Making Codec require Java 1.4 (at this
> point) will cause a rippling effect on many other projects which are
> dependent (either directly or indirectly) on this library.
>
> IMHO, Commons-Codec as well as Commons HttpClient being low level
> libraries should target as wider user base as possible. Funny enough, we
> (HttpClient) still get requests for Java 1.1.8 compatibility once in a
> while. Some people went ever as far as creating a semi-official Java
> 1.1.8 fork to cater to their specific needs. The last thing I would like
> to see is a Java 1.2.x fork in addition to that.
>
> I am not saying Codec should not go forward and adopt new features in
> the Java platform that sense for it. However, we should consider not
> only the risk of working ourselves out of existence but also the risk of
> ending up working just for ourselves.
>
> At the very least I would like to see a more coherent policy towards
> Java platform compatibility across all Commons sub-project. I believe
> there must be a common baseline we should all agree upon and then stick
> to, whatever it is.
>
> Cheers,
>
> Oleg
I still really get a strong sense that more "Tag and Branching" would be
an empowerment here, HttpClient for j2sdk 1.4 and greater could take
advantage of those features 1.4 provides (for instance "nio") while a
maintence branch on < 1.4 could maintain release for those specific JVM's.
-Mark
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [codec] More thoughts on CharSets and Encoders (references: R
E: [codec] Streamable Codec Framework)
Posted by Oleg Kalnichevski <ol...@bluewin.ch>.
> The most important phrase in Craig's email was: "As such, I'm
> personally not interested in working on any revolutionary Struts or
> Commons designs that do not presume at least J2SE 1.4 / J2EE 1.4 as the
> base platform as the minimum requirement."
Tim & Craig,
I wish I could agree with you, but unfortunately I have to say that this
is a very PC- (or let me say big-time computing) centric point of view.
There are still enough platforms that are in a widespread use where even
Java 1.2 is not available, for instance MacOS 9 and, more importantly,
all sorts of micro devices and embedded systems. True, it does not make
sense to run Struts on a PDA or on a mobile phone. However,
commons-codec being a low level library may come quite handy when
developing applications for PDAs. Same story goes for HttpClient, which
has recently become dependent on commons-codec. HttpClient in its turn
is a dependency for XML-RPM. Making Codec require Java 1.4 (at this
point) will cause a rippling effect on many other projects which are
dependent (either directly or indirectly) on this library.
IMHO, Commons-Codec as well as Commons HttpClient being low level
libraries should target as wider user base as possible. Funny enough, we
(HttpClient) still get requests for Java 1.1.8 compatibility once in a
while. Some people went ever as far as creating a semi-official Java
1.1.8 fork to cater to their specific needs. The last thing I would like
to see is a Java 1.2.x fork in addition to that.
I am not saying Codec should not go forward and adopt new features in
the Java platform that sense for it. However, we should consider not
only the risk of working ourselves out of existence but also the risk of
ending up working just for ourselves.
At the very least I would like to see a more coherent policy towards
Java platform compatibility across all Commons sub-project. I believe
there must be a common baseline we should all agree upon and then stick
to, whatever it is.
Cheers,
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [codec] More thoughts on CharSets and Encoders (references: R
E: [codec] Streamable Codec Framework)
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
What about the idea of employing more "Tag and Branch" Approaches in
Commons that parellel JVM, Servlet/JSP, Tomcat or (basically any parent
platform/dependency space)?
This way developers with an interest in maintain backward compatability
and support bugfixing to these "spaces" can continue to do so while the
Head stays more adventurous...
-Mark
Tim O'Brien wrote:
> A +1 for Craig's comments.
>
> If there are users who still have 1.2 requirements going forward, I say
> should say to them, you need to take it upon yourself to make the case
> for an upgrade, or work actively in this community to write components
> that work with 1.2.
>
> The most important phrase in Craig's email was: "As such, I'm
> personally not interested in working on any revolutionary Struts or
> Commons designs that do not presume at least J2SE 1.4 / J2EE 1.4 as the
> base platform as the minimum requirement." I am of the same persuasion,
> and if we create a community in which developers do not want to
> participate, we're working ourselves out of existence. And, I believe
> that is what we are seeing right now.
>
> Tim
>
>
>
> Craig R. McClanahan wrote:
>
>> Quoting Gary Gregory <gg...@seagullsw.com>:
>>
>>
>>
>>> (1) "eventually" is, sadly I think, a ways off in the future. See
>>> discussions on this list WRT J2ee containers, WebSphere, most common
>>> installed base of such containers, etc.
>>>
>>>
>>
>>
>> <personal-viewpoint author="craigmcc">
>>
>> As a major proponent of long-term support for existing packages that
>> want to do
>> evolutionary development, this is an important issue. My own
>> experience with
>> Struts (which still supports Servlet 2.2 / JSP 1.1) says that this is
>> important
>> for existing users. And it will continue to be. *Nobody* in the real
>> world
>> can migrate to more current technologies as fast as the developers of
>> those
>> technologies would wish that they could.
>>
>> However, I get really impatient with this reality for *future* users.
>> Many/most
>> Jakarta projects tend to focus on the "what is widely deployed now"
>> scenario --
>> but limiting ongoing development to this kind of platform is *very*
>> bad for the
>> Java platform in the long run.
>>
>> Personally, I will continue to invest effort in supporting existing
>> users of
>> the
>> Apache/Jakarta packages I contribute to. But my primary focus for future
>> efforts are going to be focused on leveraging the platforms that are more
>> current in the mainstream ... with the expectation that folks on
>> platforms that
>> don't have this current support *will* be taken care of by the time
>> that the
>> revolutionary software is (if it ever is) ready for general release.
>>
>> As such, I'm personally not interested in working on any revolutionary
>> Struts
>> or
>> Commons designs that do not presume at least J2SE 1.4 / J2EE 1.4 as
>> the base
>> platform as the minimum requirement. That's not to say that the needs of
>> exisiting pre-1.4-based users, or non-mainstream platforms that don't
>> support
>> SE/EE 1.4, aren't important --- nothing could be further from the
>> truth! -- but
>> limiting the ongoing development of Jakarta-based software (overall, the
>> convention seems to be to support JDK 1.2 as the minimum platform with
>> some
>> packages supporting 1.1 compatible versions) is going to be very
>> detrimental to
>> the long-term success of the Java platform.
>>
>> The JDK 1.2 environment was *years* ago ... when a 256mHz PC was the
>> tip of the
>> state of the art. Would you willing to accept being required to work
>> on such a
>> hardware system today?
>>
>> It's time for us to recognize that there are *millions* of mainstream
>> users,
>> who
>> *can* provide a 1.4 baseline runtime environmment -- and, as a whole, the
>> Jakarta community is not paying enough attention to what kinds of
>> capabilities
>> can not be assumed. Lets *stop* limiting our revolutionary advances
>> by an
>> assumption that we have to be backwards compatible with what (in computer
>> terms) is now considered the Iron Age of computing.
>> </personal-viewpoint>
>>
>> Craig McClanahan
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>
>>
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [codec] More thoughts on CharSets and Encoders (references: R
E: [codec] Streamable Codec Framework)
Posted by Tim O'Brien <to...@discursive.com>.
A +1 for Craig's comments.
If there are users who still have 1.2 requirements going forward, I say
should say to them, you need to take it upon yourself to make the case
for an upgrade, or work actively in this community to write components
that work with 1.2.
The most important phrase in Craig's email was: "As such, I'm
personally not interested in working on any revolutionary Struts or
Commons designs that do not presume at least J2SE 1.4 / J2EE 1.4 as the
base platform as the minimum requirement." I am of the same persuasion,
and if we create a community in which developers do not want to
participate, we're working ourselves out of existence. And, I believe
that is what we are seeing right now.
Tim
Craig R. McClanahan wrote:
>Quoting Gary Gregory <gg...@seagullsw.com>:
>
>
>
>>(1) "eventually" is, sadly I think, a ways off in the future. See
>>discussions on this list WRT J2ee containers, WebSphere, most common
>>installed base of such containers, etc.
>>
>>
>>
>
><personal-viewpoint author="craigmcc">
>
>As a major proponent of long-term support for existing packages that want to do
>evolutionary development, this is an important issue. My own experience with
>Struts (which still supports Servlet 2.2 / JSP 1.1) says that this is important
>for existing users. And it will continue to be. *Nobody* in the real world
>can migrate to more current technologies as fast as the developers of those
>technologies would wish that they could.
>
>However, I get really impatient with this reality for *future* users.
>Many/most
>Jakarta projects tend to focus on the "what is widely deployed now" scenario --
>but limiting ongoing development to this kind of platform is *very* bad for the
>Java platform in the long run.
>
>Personally, I will continue to invest effort in supporting existing users of
>the
>Apache/Jakarta packages I contribute to. But my primary focus for future
>efforts are going to be focused on leveraging the platforms that are more
>current in the mainstream ... with the expectation that folks on platforms that
>don't have this current support *will* be taken care of by the time that the
>revolutionary software is (if it ever is) ready for general release.
>
>As such, I'm personally not interested in working on any revolutionary Struts
>or
>Commons designs that do not presume at least J2SE 1.4 / J2EE 1.4 as the base
>platform as the minimum requirement. That's not to say that the needs of
>exisiting pre-1.4-based users, or non-mainstream platforms that don't support
>SE/EE 1.4, aren't important --- nothing could be further from the truth! -- but
>limiting the ongoing development of Jakarta-based software (overall, the
>convention seems to be to support JDK 1.2 as the minimum platform with some
>packages supporting 1.1 compatible versions) is going to be very detrimental to
>the long-term success of the Java platform.
>
>The JDK 1.2 environment was *years* ago ... when a 256mHz PC was the tip of the
>state of the art. Would you willing to accept being required to work on such a
>hardware system today?
>
>It's time for us to recognize that there are *millions* of mainstream users,
>who
>*can* provide a 1.4 baseline runtime environmment -- and, as a whole, the
>Jakarta community is not paying enough attention to what kinds of capabilities
>can not be assumed. Lets *stop* limiting our revolutionary advances by an
>assumption that we have to be backwards compatible with what (in computer
>terms) is now considered the Iron Age of computing.
></personal-viewpoint>
>
>Craig McClanahan
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org