You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Oleg Kalnichevski <ol...@apache.org> on 2006/11/22 14:55:52 UTC
[HttpCore] HttpCore is (pretty much) feature complete
Odi, Mike, Roland, and all
As far as I am concerned HttpCore at this is pretty much feature
complete and is ready to move into API stabilization phase. I have
committed all the ideas I had in mind to code and believe HttpCore is
the shape to start moving toward the first BETA _unless_ there is
massively more feedback (negative or positive) from other contributors.
I think the classic I/O code even in its present form is quite stable
and well optimized. There is room for some tweaks here and there but I
do not foresee any more major changes. NIO code may still be quite raw,
but as the protocol components proved flexible enough to be usable with
blocking and non-blocking (NIO) transports, I am cautiously optimistic
NIO extensions will not require a complete rewrite.
If I hear no objections I will call a vote on HttpCore 4.0-ALPHA3
release tonight
Cheers,
Evil Comrade Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: [HttpCore] HttpCore is (pretty much) feature complete
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Wed, 2006-11-22 at 14:59 +0100, Ortwin Glück wrote:
> Oleg,
>
> Fair enough. I would like to look through the code (and complete API doc
> on the way) before. What about voting next Monday?
>
Sure thing. Take all the time it takes
Cheers
Oleg
> Odi
>
> Oleg Kalnichevski wrote:
> > Odi, Mike, Roland, and all
> >
> > As far as I am concerned HttpCore at this is pretty much feature
> > complete and is ready to move into API stabilization phase. I have
> > committed all the ideas I had in mind to code and believe HttpCore is
> > the shape to start moving toward the first BETA _unless_ there is
> > massively more feedback (negative or positive) from other contributors.
> >
> > I think the classic I/O code even in its present form is quite stable
> > and well optimized. There is room for some tweaks here and there but I
> > do not foresee any more major changes. NIO code may still be quite raw,
> > but as the protocol components proved flexible enough to be usable with
> > blocking and non-blocking (NIO) transports, I am cautiously optimistic
> > NIO extensions will not require a complete rewrite.
> >
> > If I hear no objections I will call a vote on HttpCore 4.0-ALPHA3
> > release tonight
> >
> > Cheers,
> >
> > Evil Comrade Oleg
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: [HttpCore] HttpCore is (pretty much) feature complete
Posted by Ortwin Glück <od...@odi.ch>.
Oleg,
Fair enough. I would like to look through the code (and complete API doc
on the way) before. What about voting next Monday?
Odi
Oleg Kalnichevski wrote:
> Odi, Mike, Roland, and all
>
> As far as I am concerned HttpCore at this is pretty much feature
> complete and is ready to move into API stabilization phase. I have
> committed all the ideas I had in mind to code and believe HttpCore is
> the shape to start moving toward the first BETA _unless_ there is
> massively more feedback (negative or positive) from other contributors.
>
> I think the classic I/O code even in its present form is quite stable
> and well optimized. There is room for some tweaks here and there but I
> do not foresee any more major changes. NIO code may still be quite raw,
> but as the protocol components proved flexible enough to be usable with
> blocking and non-blocking (NIO) transports, I am cautiously optimistic
> NIO extensions will not require a complete rewrite.
>
> If I hear no objections I will call a vote on HttpCore 4.0-ALPHA3
> release tonight
>
> Cheers,
>
> Evil Comrade Oleg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
>
--
[web] http://www.odi.ch/
[blog] http://www.odi.ch/weblog/
[pgp] key 0x81CF3416
finger print F2B1 B21F F056 D53E 5D79 A5AF 02BE 70F5 81CF 3416
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: [HttpCore] HttpCore is (pretty much) feature complete
Posted by Roland Weber <ht...@dubioso.net>.
Hi Oleg,
> Going BETA will not preclude us from adding new features to the HttpCore
> API. We will no longer be able remove / rename classes / methods and
> will have to use deprecation in order to preserve compile API
> compatibility BETA-1 onwards. So, no more radical rewrites, but we still
> should have enough room for adding new stuff.
Yep. I just want to get that in from the very first beta.
Just so nobody can blame that we've forgotten it ;-)
> Anyways, I expect more than one ALPHA before we are ready to freeze the
> API and by any means would like to see the first ALPHA of HttpClient
> released before the first BETA of HttpCore.
No objections from my side :-)
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: [HttpCore] HttpCore is (pretty much) feature complete
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Thu, 2006-11-23 at 19:32 +0100, Roland Weber wrote:
> Hi Oleg,
>
> we are still missing runtime support for determining the
> versions of (all) HttpComponents in the JVM. No matter
> what kind of versioning we're going to use for a yet to be
> discussed all-in-one delivery or not, we can't give support
> in the long run without a simple way for users to send us
> a full list of the components and versions. I see the
> foundation of this mechanism as part of HttpCore, with
> some properties file in each of our distributed JARs.
> I haven't brought this up yet since I don't have time to
> work on a patch, but I think we have to add that before
> going BETA. Personally, I expect another alpha anyway,
> so there is no need to hurry.
>
> cheers,
> Roland
>
Hi Roland,
Going BETA will not preclude us from adding new features to the HttpCore
API. We will no longer be able remove / rename classes / methods and
will have to use deprecation in order to preserve compile API
compatibility BETA-1 onwards. So, no more radical rewrites, but we still
should have enough room for adding new stuff.
Anyways, I expect more than one ALPHA before we are ready to freeze the
API and by any means would like to see the first ALPHA of HttpClient
released before the first BETA of HttpCore.
Cheers,
Oleg
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: [HttpCore] HttpCore is (pretty much) feature complete
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Fri, 2006-11-24 at 11:40 +0100, Ortwin Glück wrote:
>
> sebb wrote:
> > Another possibility would be to include a field or method in each java
> > source file to return the SVN revision. There would need to be a
> > method to extract this information and display it to the user (or
> > write a file), and it could produce a lot of detail.
>
> Overkill IMHO, as we only need the release number, not the file version.
>
> Other components (Xalan, Avalon, JUnit, JBoss etc.) use a class called
> Version with a single static method in their base package. That version
> number can be filled in automatically at build time.
>
> Odi
>
Folks,
I think at some point of time we should take this discussion to
general@jakarta. This issue directly concerns several projects, Commons
in the first place, and we should try to work out a consistent
Jakarta-wide bundling strategy
Oleg
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: [HttpCore] HttpCore is (pretty much) feature complete
Posted by Roland Weber <ht...@dubioso.net>.
Hi all,
Ortwin Glück wrote:
> Other components (Xalan, Avalon, JUnit, JBoss etc.) use a class called
> Version with a single static method in their base package. That version
> number can be filled in automatically at build time.
A single class and build time versioning is also my preference. I'd
like to include an official release number (if one is given to Maven)
and a timestamp. But we can put in the SVN revision as well. Sebastian,
thanks for the suggestion.
My biggest concern are people hacking up modifications from a sourceball
and compiling the resulting code. Release number (if taken from a file)
and SVN revision wouldn't catch that, hence the timestamp.
I'm also fine with Oleg's idea of taking this discussion to general
in the future. I expect different projects to have different needs,
though. For example I can easily imagine each commons-XXX to ship
it's own Version class, but would prefer to have only one for all
of HttpComponents. A common format for the properties files would
still be welcome. Somebody's probably going to suggest a tool that
automatically scans a bunch of JAR files for such version info :-)
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: [HttpCore] HttpCore is (pretty much) feature complete
Posted by Ortwin Glück <od...@odi.ch>.
sebb wrote:
> Another possibility would be to include a field or method in each java
> source file to return the SVN revision. There would need to be a
> method to extract this information and display it to the user (or
> write a file), and it could produce a lot of detail.
Overkill IMHO, as we only need the release number, not the file version.
Other components (Xalan, Avalon, JUnit, JBoss etc.) use a class called
Version with a single static method in their base package. That version
number can be filled in automatically at build time.
Odi
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: [HttpCore] HttpCore is (pretty much) feature complete
Posted by sebb <se...@gmail.com>.
On 23/11/06, Roland Weber <ht...@dubioso.net> wrote:
> Hi Oleg,
>
> we are still missing runtime support for determining the
> versions of (all) HttpComponents in the JVM. No matter
> what kind of versioning we're going to use for a yet to be
> discussed all-in-one delivery or not, we can't give support
> in the long run without a simple way for users to send us
> a full list of the components and versions. I see the
> foundation of this mechanism as part of HttpCore, with
> some properties file in each of our distributed JARs.
The properties file could include a version number auto-generated from
the SVN revision.
You would need to ensure that it was updated just before a release,
e.g. with a "normal" version number.
Another possibility would be to include a field or method in each java
source file to return the SVN revision. There would need to be a
method to extract this information and display it to the user (or
write a file), and it could produce a lot of detail.
Just a thought.
We use this technique in JMeter for some files that need to be kept in
step with each other, although the revisions are only used for the
JUnit tests, not for identifying JMeter itself.
S.
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: [HttpCore] HttpCore is (pretty much) feature complete
Posted by Roland Weber <ht...@dubioso.net>.
Hi Oleg,
we are still missing runtime support for determining the
versions of (all) HttpComponents in the JVM. No matter
what kind of versioning we're going to use for a yet to be
discussed all-in-one delivery or not, we can't give support
in the long run without a simple way for users to send us
a full list of the components and versions. I see the
foundation of this mechanism as part of HttpCore, with
some properties file in each of our distributed JARs.
I haven't brought this up yet since I don't have time to
work on a patch, but I think we have to add that before
going BETA. Personally, I expect another alpha anyway,
so there is no need to hurry.
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: [HttpCore] HttpCore is (pretty much) feature complete
Posted by Ortwin Glück <od...@odi.ch>.
Oleg,
I have completed my review. From my point of view the API is very
sensible. Please feel free to call for a release.
Kind regards
Odi
Oleg Kalnichevski wrote:
> Odi, Mike, Roland, and all
>
> As far as I am concerned HttpCore at this is pretty much feature
> complete and is ready to move into API stabilization phase. I have
> committed all the ideas I had in mind to code and believe HttpCore is
> the shape to start moving toward the first BETA _unless_ there is
> massively more feedback (negative or positive) from other contributors.
>
> I think the classic I/O code even in its present form is quite stable
> and well optimized. There is room for some tweaks here and there but I
> do not foresee any more major changes. NIO code may still be quite raw,
> but as the protocol components proved flexible enough to be usable with
> blocking and non-blocking (NIO) transports, I am cautiously optimistic
> NIO extensions will not require a complete rewrite.
>
> If I hear no objections I will call a vote on HttpCore 4.0-ALPHA3
> release tonight
>
> Cheers,
>
> Evil Comrade Oleg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org