Re: Next Release? What about next release version number?
Seems like a good time to introduce the separate request/response design. We could create HttpRequest and HttpResponse interfaces. That way we could have HttpMethodBase, et al implement both. To solve the interface problem we could just explicitly comment HttpRequest/HttpResponse saying that they should not be implemented outside of HttpClient. Mike Eric Johnson wrote: Oleg, I think we're largely in agreement, then, but are out of alignment by a matter of degrees. Rather than removing classes right away, I'd like to see them deprecated for at least one major release. That leaves clients with the "crumbs" that they can follow to migrate their code, rather than discovering that their code is completely broken and must be rewritten. So I would say that we cannot *dump* the HttpMethod interface just yet. As a separate design issue, I don't think HttpMethodBase *should* be considered the "base" from which all methods must inherit. It simply does way too much, so I think there needs to be an intermediate class, which I would call AbstractHttpMethod. -Eric. Kalnichevski, Oleg wrote: Eric, I find it hard to disagree with you, being a fan of incremental, iterative development myself. I just regret all the energy and time that went into 2.0 API compatibility workarounds so far. If we go with 3.0 then I would like to see a few more 2.0 API breakages that had been turned down for the sake of maintaining 2.0 compatibility, especially in the exception handling framework. I would also suggest HttpMethod interface be completely gotten rid of and the abstract HttpMethodBase renamed to HttpMethod. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ArrayIndexOutOfBoundsException while reading
I agree that working around JVM bugs is annoying, but in most cases there's really not much else you can do. However, it's not acceptable to allow a runtime exception to kill code that should otherwise work. The bug so far has only been reported with Windows (but that could be because there's just a lot more windows users). On 1.3.X versions of Java, the bug stems from the socketRead method. On 1.4.X versions, it stems from socketRead0. If HttpClient is hesitant to add the workaround code, it's no big deal -- we already are using a modified version, so I can just insert an AIOOBExceptionStreamHandler of sorts around the existing streams. It might be useful to have this in HttpClient, though, as it could bite some other heavy-duty users. Thanks, Sam On Thursday, January 8, 2004, at 01:10 PM, Ingo Brunberg wrote: To work around a bug in the Java VM in this manner seems a bad idea to me. As I have never seen this myself, I guess only Windows platforms are affected? What are the Sun engineers saying? Regards, Ingo Hi all, Under some exceptional circumstances, reading from a SocketInputStream can cause an ArrayIndexOutOfBoundsException. We have seen this occur in many other places (non HttpClient related), and since including HttpClient a few bugs have been reported with it as well. The exact cause is unknown and not easily reproduced, and the exception actually occurs in native code (java.net.SocketInputStream.socketRead0). I suggest adding a wrapper input stream around the underlying inputstream that extends all read-style calls, catches ArrayIndexOutOfBoundsException and rethrows it as an IOException. An example bug report demonstrating this bug can be at: http://bugs.limewire.com/bugs/searching.jsp?l=80&c=46&m=-1_-1&os=- 1&offset=15 . (Note that we're currently redoing the internals of the bug server, so if that link doesn't work, you can reach the bug reports yourself by going to http://bugs.limewire.com/bugs/search.jsp , choosing or typing "java.lang.ArrayIndexOutOfBoundsException" as the exception to search for, and choosing or typing "org.apache.commons.httpclient.HttpParser" as the class that the error occurs in.) Thanks, Sam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ArrayIndexOutOfBoundsException while reading
To work around a bug in the Java VM in this manner seems a bad idea to me. As I have never seen this myself, I guess only Windows platforms are affected? What are the Sun engineers saying? Regards, Ingo > Hi all, > > Under some exceptional circumstances, reading from a SocketInputStream > can cause an ArrayIndexOutOfBoundsException. We have seen this occur > in many other places (non HttpClient related), and since including > HttpClient a few bugs have been reported with it as well. The exact > cause is unknown and not easily reproduced, and the exception actually > occurs in native code (java.net.SocketInputStream.socketRead0). I > suggest adding a wrapper input stream around the underlying inputstream > that extends all read-style calls, catches > ArrayIndexOutOfBoundsException and rethrows it as an IOException. > > An example bug report demonstrating this bug can be at: > http://bugs.limewire.com/bugs/searching.jsp?l=80&c=46&m=-1_-1&os=- > 1&offset=15 . (Note that we're currently redoing the internals of the > bug server, so if that link doesn't work, you can reach the bug reports > yourself by going to http://bugs.limewire.com/bugs/search.jsp , > choosing or typing "java.lang.ArrayIndexOutOfBoundsException" as the > exception to search for, and choosing or typing > "org.apache.commons.httpclient.HttpParser" as the class that the error > occurs in.) > > Thanks, > Sam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ArrayIndexOutOfBoundsException while reading
Hi all, Under some exceptional circumstances, reading from a SocketInputStream can cause an ArrayIndexOutOfBoundsException. We have seen this occur in many other places (non HttpClient related), and since including HttpClient a few bugs have been reported with it as well. The exact cause is unknown and not easily reproduced, and the exception actually occurs in native code (java.net.SocketInputStream.socketRead0). I suggest adding a wrapper input stream around the underlying inputstream that extends all read-style calls, catches ArrayIndexOutOfBoundsException and rethrows it as an IOException. An example bug report demonstrating this bug can be at: http://bugs.limewire.com/bugs/searching.jsp?l=80&c=46&m=-1_-1&os=- 1&offset=15 . (Note that we're currently redoing the internals of the bug server, so if that link doesn't work, you can reach the bug reports yourself by going to http://bugs.limewire.com/bugs/search.jsp , choosing or typing "java.lang.ArrayIndexOutOfBoundsException" as the exception to search for, and choosing or typing "org.apache.commons.httpclient.HttpParser" as the class that the error occurs in.) Thanks, Sam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Next Release? What about next release version number?
Oh no, here we go again :) I agree that 2.1 is probably no longer applicable given the number of API and other changes that are occurring. 3.0 sounds like the logical next step. While I think this gives us some license to change a few major things, I do not think we should go off the deep end. Mike Kalnichevski, Oleg wrote: Folks, Before we can start articulating our further plans, there's one important decision to be made which cannot be put off any longer. We have to decide on the next release number. I am afraid with all the recent changes (new preference architecture, HttpMethodDirector, better exception handling framework, saner authentication code, Commons-Codec, and much more) we can no longer consider the development version of HttpClient a minor release. Version 2.1 would no longer be appropriate, I fear. Too much has changed, even though the HttpMethod interface, the hallmark of 2.0 API architectural ugliness, is still there. Yet, version 3.0 is so tightly associated in my mind with the much talked about complete API overhaul, that I am hesitant to simply move one major version ahead with the current release, leaving the API redesign for 4.0. I personally tend to lean towards calling the next release 2.5. It is unconventional, but, I feel, best reflects the magnitude of change in HttpClient code. What do you think? Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Next Release?
I agree. A coherent roadmap, or something of the like, would be quite useful. Don't be too hard on yourself, I've always found your writing to be quite good. Mike Kalnichevski, Oleg wrote: Makes sense. Anyways, some sort of coherent statement with regards to the post-2.0 development directions is pretty much a must for the 2.0 Final. I think I could handle this task while you, guys, concentrate on reviewing the pending patches, even though I am a terrible writer. Oleg -Original Message- From: Ortwin Glück [mailto:[EMAIL PROTECTED] Sent: Thursday, January 08, 2004 11:36 To: Commons HttpClient Project Subject: Re: Next Release? Looking at Bugzilla there are a few bugs with target milestone 2.1 Final and 3.0 Final. We can at least summarize these up or just provide links to Bugzilla. This is at least some sort of minimal planning. Also your quote to Srinivas could go on that page. I means if we all have ideas about a schedule in our heads. It's just a matter of communicating them. But nobody will ever point their finger at us if we do not stick to those plans and change them for good reason. Odi Kalnichevski, Oleg wrote: Odi, That would surely be a much welcome addition. However, up to now we have not been terribly good at planning things in advance and then sticking to what has been agreed upon. With the current limited resource pool I can hardly see anything more 'we wanna make HttpClient better' kind of roadmap we would manage to live up to Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Next Release? What about next release version number?
> Rather than removing classes right away, I'd like to see them deprecated > for at least one major release. That leaves clients with the "crumbs" > that they can follow to migrate their code, rather than discovering that > their code is completely broken and must be rewritten. So I would say > that we cannot *dump* the HttpMethod interface just yet. Eric, There's one thing I REALLY dislike about this idea is that deprecation of HttpMethod interface will cause hundreds of deprecation warnings, which I personally find irritating. Please for the sake of my sanity, as I deal with HttpClient on a daily basis, if this is to be done, than it should be done as late in the process as possible. > As a separate design issue, I don't think HttpMethodBase *should* be > considered the "base" from which all methods must inherit. It simply > does way too much, so I think there needs to be an intermediate class, > which I would call AbstractHttpMethod. I am afraid I am not quite getting the point here. An intermediate class between what? Should AbstractHttpMethod implement HttpMethod and HttpMethodBase extend AbstractHttpMethod? Is that what you are saying? Which parts of the present HttpMethodBase code should be moved into AbstractHttpMethod and what should remain in HttpMethodBase? Frankly I do not think I see a lot of benefits in doing so. The concept of a method as an entity that combines HTTP request and HTTP response is fundamentally flawed. It should rather be completely done away with or left alone, IMO. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Next Release? What about next release version number?
Oleg, I think we're largely in agreement, then, but are out of alignment by a matter of degrees. Rather than removing classes right away, I'd like to see them deprecated for at least one major release. That leaves clients with the "crumbs" that they can follow to migrate their code, rather than discovering that their code is completely broken and must be rewritten. So I would say that we cannot *dump* the HttpMethod interface just yet. As a separate design issue, I don't think HttpMethodBase *should* be considered the "base" from which all methods must inherit. It simply does way too much, so I think there needs to be an intermediate class, which I would call AbstractHttpMethod. -Eric. Kalnichevski, Oleg wrote: Eric, I find it hard to disagree with you, being a fan of incremental, iterative development myself. I just regret all the energy and time that went into 2.0 API compatibility workarounds so far. If we go with 3.0 then I would like to see a few more 2.0 API breakages that had been turned down for the sake of maintaining 2.0 compatibility, especially in the exception handling framework. I would also suggest HttpMethod interface be completely gotten rid of and the abstract HttpMethodBase renamed to HttpMethod. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Next Release? What about next release version number?
Kalnichevski, Oleg wrote: Eric, I find it hard to disagree with you, being a fan of incremental, iterative development myself. I just regret all the energy and time that went into 2.0 API compatibility workarounds so far. If we go with 3.0 then I would like to see a few more 2.0 API breakages that had been turned down for the sake of maintaining 2.0 compatibility, especially in the exception handling framework. I would also suggest HttpMethod interface be completely gotten rid of and the abstract HttpMethodBase renamed to HttpMethod. Oleg Sure. I am in favour of that as well. CVS HEAD is still pre alpha and already IS breaking 2.0 compatibility. So I don't see why we should not go ahead and fix this damn baby... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Next Release? What about next release version number?
Ortwin Glück wrote: Why not just release the current one as 3.0 and make a 4.0 after that? What's wrong with that? We all want a release SOON and not within months. If we make more API changes for 4.0 who cares. Sorry, I was talking about CVS HEAD here. Forget the "SOON". - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Next Release? What about next release version number?
Eric, I find it hard to disagree with you, being a fan of incremental, iterative development myself. I just regret all the energy and time that went into 2.0 API compatibility workarounds so far. If we go with 3.0 then I would like to see a few more 2.0 API breakages that had been turned down for the sake of maintaining 2.0 compatibility, especially in the exception handling framework. I would also suggest HttpMethod interface be completely gotten rid of and the abstract HttpMethodBase renamed to HttpMethod. Oleg -Original Message- From: Eric Johnson [mailto:[EMAIL PROTECTED] Sent: Thursday, January 08, 2004 14:53 To: Commons HttpClient Project Subject: Re: Next Release? What about next release version number? Oleg, I understand your thinking, but my thinking it is that it is far more important to release new stable releases often, rather than worrying about their version number. Re-exposing my bias, I strongly prefer incremental change. With many compliments to the incredible work that has gone into the next release so far (the presumed 2.1, now 3.0?), I don't see any reason to hesitate calling it 3.0. At the same time, I don't think that means that we should consider jumping on radical changes beyond what has been done already. The version number tells me that it is not going to be a drop-in compatible change, but the small number of API changes is actually a good thing, in that clients can migrate quickly. My previous comment was there only to prod for consideration of low impact changes that might make it easier to maintain HttpClient moving forward. For example, the one change that occurs to me - get rid of the illusion (delusion?) that clients could *ever* successfully implement the HttpMethod interface. Perhaps deprecate the interface, and override it with an abstract base class, which clients would be expected to override instead. This isn't a huge change, and adds no additional functionality, but adds a lot of flexibility for enabling backward compatible enhancements. -Eric. Kalnichevski, Oleg wrote: >>Thinking about it as a 3.0 release, though, I think we should make an >>effort to change the 3.0 API so that we're more confident of our ability >>to make critical incremental changes. >> >> > >I hate revisiting the same discussions that raged on this forum 6 months ago, but >this is exactly the point. If we decide to go 3.0, then we should stop playing 'bend >2.0 API around' kind of games and should get down to some serious work (which would >inevitably delay the next stable by maany months, if not years, judging by our >current rate of progress) > >Oleg > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Next Release? What about next release version number?
Kalnichevski, Oleg wrote: Version inflation is as evil and misleading, IMHO Sure. Especially in Java, where Jar-Versioning is a somewhat unsolved problem (okay you CAN solve it with classloaders but it's a PITA). Still, you were taling about years :-) Anyways, why do not we have all HttpClient regualrs vote on this issue and get it over with? We should not forget to ask/notify other Commons projects that use HttpClient, such as Slide. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Next Release? What about next release version number?
Oleg, I understand your thinking, but my thinking it is that it is far more important to release new stable releases often, rather than worrying about their version number. Re-exposing my bias, I strongly prefer incremental change. With many compliments to the incredible work that has gone into the next release so far (the presumed 2.1, now 3.0?), I don't see any reason to hesitate calling it 3.0. At the same time, I don't think that means that we should consider jumping on radical changes beyond what has been done already. The version number tells me that it is not going to be a drop-in compatible change, but the small number of API changes is actually a good thing, in that clients can migrate quickly. My previous comment was there only to prod for consideration of low impact changes that might make it easier to maintain HttpClient moving forward. For example, the one change that occurs to me - get rid of the illusion (delusion?) that clients could *ever* successfully implement the HttpMethod interface. Perhaps deprecate the interface, and override it with an abstract base class, which clients would be expected to override instead. This isn't a huge change, and adds no additional functionality, but adds a lot of flexibility for enabling backward compatible enhancements. -Eric. Kalnichevski, Oleg wrote: Thinking about it as a 3.0 release, though, I think we should make an effort to change the 3.0 API so that we're more confident of our ability to make critical incremental changes. I hate revisiting the same discussions that raged on this forum 6 months ago, but this is exactly the point. If we decide to go 3.0, then we should stop playing 'bend 2.0 API around' kind of games and should get down to some serious work (which would inevitably delay the next stable by maany months, if not years, judging by our current rate of progress) Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Next Release? What about next release version number?
> What's wrong with that? Version inflation is as evil and misleading, IMHO Anyways, why do not we have all HttpClient regualrs vote on this issue and get it over with? Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Next Release? What about next release version number?
Kalnichevski, Oleg wrote: I hate revisiting the same discussions that raged on this forum 6 months ago, but this is exactly the point. If we decide to go 3.0, then we should stop playing 'bend 2.0 API around' kind of games and should get down to some serious work (which would inevitably delay the next stable by maany months, if not years, judging by our current rate of progress) Oleg Why not just release the current one as 3.0 and make a 4.0 after that? What's wrong with that? We all want a release SOON and not within months. If we make more API changes for 4.0 who cares. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Next Release? What about next release version number?
> Thinking about it as a 3.0 release, though, I think we should make an > effort to change the 3.0 API so that we're more confident of our ability > to make critical incremental changes. I hate revisiting the same discussions that raged on this forum 6 months ago, but this is exactly the point. If we decide to go 3.0, then we should stop playing 'bend 2.0 API around' kind of games and should get down to some serious work (which would inevitably delay the next stable by maany months, if not years, judging by our current rate of progress) Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Next Release? What about next release version number?
I'm with Odi. I wouldn't hesitate to call it 3.0. As far as the use of HttpClient within my company, calling it 2.X would be misleading in that it is not a drop-in enhancement over the 2.0 version. If it is called 2.X, I'd be in the position of having to tell others not to use it, in spite of the version number. Thinking about it as a 3.0 release, though, I think we should make an effort to change the 3.0 API so that we're more confident of our ability to make critical incremental changes. Who am I to talk, though? I've not been contributing much lately -Eric. Kalnichevski, Oleg wrote: Folks, Before we can start articulating our further plans, there's one important decision to be made which cannot be put off any longer. We have to decide on the next release number. I am afraid with all the recent changes (new preference architecture, HttpMethodDirector, better exception handling framework, saner authentication code, Commons-Codec, and much more) we can no longer consider the development version of HttpClient a minor release. Version 2.1 would no longer be appropriate, I fear. Too much has changed, even though the HttpMethod interface, the hallmark of 2.0 API architectural ugliness, is still there. Yet, version 3.0 is so tightly associated in my mind with the much talked about complete API overhaul, that I am hesitant to simply move one major version ahead with the current release, leaving the API redesign for 4.0. I personally tend to lean towards calling the next release 2.5. It is unconventional, but, I feel, best reflects the magnitude of change in HttpClient code. What do you think? Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Next Release? What about next release version number?
Kalnichevski, Oleg wrote: Before we can start articulating our further plans, there's one important decision to be made which cannot be put off any longer. We have to decide on the next release number. [...] I personally tend to lean towards calling the next release 2.5. It is unconventional, but, I feel, best reflects the magnitude of change in HttpClient code. What do you think? API has changed from 2.0. So we MUST call it 3.0. Everything else is misleading. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Next Release? What about next release version number?
Folks, Before we can start articulating our further plans, there's one important decision to be made which cannot be put off any longer. We have to decide on the next release number. I am afraid with all the recent changes (new preference architecture, HttpMethodDirector, better exception handling framework, saner authentication code, Commons-Codec, and much more) we can no longer consider the development version of HttpClient a minor release. Version 2.1 would no longer be appropriate, I fear. Too much has changed, even though the HttpMethod interface, the hallmark of 2.0 API architectural ugliness, is still there. Yet, version 3.0 is so tightly associated in my mind with the much talked about complete API overhaul, that I am hesitant to simply move one major version ahead with the current release, leaving the API redesign for 4.0. I personally tend to lean towards calling the next release 2.5. It is unconventional, but, I feel, best reflects the magnitude of change in HttpClient code. What do you think? Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Next Release?
Kalnichevski, Oleg wrote: Makes sense. Anyways, some sort of coherent statement with regards to the post-2.0 development directions is pretty much a must for the 2.0 Final. I think I could handle this task while you, guys, concentrate on reviewing the pending patches, even though I am a terrible writer. Oleg *grin* Excellent! I can always put in my ideas afterwards... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Next Release?
Makes sense. Anyways, some sort of coherent statement with regards to the post-2.0 development directions is pretty much a must for the 2.0 Final. I think I could handle this task while you, guys, concentrate on reviewing the pending patches, even though I am a terrible writer. Oleg -Original Message- From: Ortwin Glück [mailto:[EMAIL PROTECTED] Sent: Thursday, January 08, 2004 11:36 To: Commons HttpClient Project Subject: Re: Next Release? Looking at Bugzilla there are a few bugs with target milestone 2.1 Final and 3.0 Final. We can at least summarize these up or just provide links to Bugzilla. This is at least some sort of minimal planning. Also your quote to Srinivas could go on that page. I means if we all have ideas about a schedule in our heads. It's just a matter of communicating them. But nobody will ever point their finger at us if we do not stick to those plans and change them for good reason. Odi Kalnichevski, Oleg wrote: > Odi, > That would surely be a much welcome addition. However, up to now we have not been > terribly good at planning things in advance and then sticking to what has been > agreed upon. With the current limited resource pool I can hardly see anything more > 'we wanna make HttpClient better' kind of roadmap we would manage to live up to > > Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Next Release?
Looking at Bugzilla there are a few bugs with target milestone 2.1 Final and 3.0 Final. We can at least summarize these up or just provide links to Bugzilla. This is at least some sort of minimal planning. Also your quote to Srinivas could go on that page. I means if we all have ideas about a schedule in our heads. It's just a matter of communicating them. But nobody will ever point their finger at us if we do not stick to those plans and change them for good reason. Odi Kalnichevski, Oleg wrote: Odi, That would surely be a much welcome addition. However, up to now we have not been terribly good at planning things in advance and then sticking to what has been agreed upon. With the current limited resource pool I can hardly see anything more 'we wanna make HttpClient better' kind of roadmap we would manage to live up to Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Next Release?
Hi All, I completely understand. Only reason I was curious was cos the web-site mentions all the big stuff planned for 2.1. Thank you all for your efforts. srini Kalnichevski, Oleg wrote: Srinivas, Making predictions about release dates for open-source projects is a nasty business. The final 2.0 release was initially anticipated in June-July 2003. It did not quite work out for us. Even though 2.0 is _almost_ finished (we have not been seeing any major bugs since September 2003 I believe) it may still take a month or two to get everything finalized. There's one thing I am pretty confident about is that we will get 2.0rc3 out sometime this month. If no significant problems are reported for two weeks or so past 2.0rc3, it will be declared THE 2.0 release. As to the development branch (currently dubbed 2.1) I would love to see the first public Alpha ready by March. Oleg -Original Message- From: Srinivas Vemula [mailto:[EMAIL PROTECTED] Sent: Thursday, January 08, 2004 10:57 To: Commons HttpClient Project Subject: Next Release? Hi, When are u planning to make the next release?? srini -- Srinivas Vemula +91 40 23547826- Ext 201 Associate Consultant +91 40 23541447 (Fax) Mensamind+91 98497-42720 (Mobile) Hyderabad India http://www.mensamind.com DISCLAIMER The information contained in this e-mail is confidential and intended for the named recipient(s) only. If you are not an intended recipient of this email you must not copy, distribute or take any further action in reliance on it. You should delete it and notify the sender immediately. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Next Release?
Odi, That would surely be a much welcome addition. However, up to now we have not been terribly good at planning things in advance and then sticking to what has been agreed upon. With the current limited resource pool I can hardly see anything more 'we wanna make HttpClient better' kind of roadmap we would manage to live up to Oleg -Original Message- From: Ortwin Glück [mailto:[EMAIL PROTECTED] Sent: Thursday, January 08, 2004 11:12 To: Commons HttpClient Project Subject: Re: Next Release? Committers, what about publishing a roadmap (replacing the status page) on the HttpClient project website? It seems of a general intrest to know what the projects status is and what are the next steps. I don't mean to publish actual dates but general ideas of where we are going. We can use the release plan file from the http client root directory as a source of information. Odi Srinivas Vemula wrote: > Hi, >When are u planning to make the next release?? > srini > -- _ NOSE applied intelligence ag ortwin glück [www] http://www.nose.ch software engineer [email] [EMAIL PROTECTED] hardturmstrasse 171 [pgp key] 0x81CF3416 8005 zürich [office] +41-1-277 57 35 switzerland [fax] +41-1-277 57 12 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Next Release?
Srinivas, Making predictions about release dates for open-source projects is a nasty business. The final 2.0 release was initially anticipated in June-July 2003. It did not quite work out for us. Even though 2.0 is _almost_ finished (we have not been seeing any major bugs since September 2003 I believe) it may still take a month or two to get everything finalized. There's one thing I am pretty confident about is that we will get 2.0rc3 out sometime this month. If no significant problems are reported for two weeks or so past 2.0rc3, it will be declared THE 2.0 release. As to the development branch (currently dubbed 2.1) I would love to see the first public Alpha ready by March. Oleg -Original Message- From: Srinivas Vemula [mailto:[EMAIL PROTECTED] Sent: Thursday, January 08, 2004 10:57 To: Commons HttpClient Project Subject: Next Release? Hi, When are u planning to make the next release?? srini -- Srinivas Vemula +91 40 23547826- Ext 201 Associate Consultant +91 40 23541447 (Fax) Mensamind+91 98497-42720 (Mobile) Hyderabad India http://www.mensamind.com DISCLAIMER The information contained in this e-mail is confidential and intended for the named recipient(s) only. If you are not an intended recipient of this email you must not copy, distribute or take any further action in reliance on it. You should delete it and notify the sender immediately. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Next Release?
Committers, what about publishing a roadmap (replacing the status page) on the HttpClient project website? It seems of a general intrest to know what the projects status is and what are the next steps. I don't mean to publish actual dates but general ideas of where we are going. We can use the release plan file from the http client root directory as a source of information. Odi Srinivas Vemula wrote: Hi, When are u planning to make the next release?? srini -- _ NOSE applied intelligence ag ortwin glück [www] http://www.nose.ch software engineer [email] [EMAIL PROTECTED] hardturmstrasse 171 [pgp key] 0x81CF3416 8005 zürich [office] +41-1-277 57 35 switzerland [fax] +41-1-277 57 12 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 25529] Redesign of HTTP authentication framework
Kalnichevski, Oleg wrote: Odi, I would very much appreciate that. It is a fairly large patch, difficult to maintain up-to-date as the CVS content mutates. It block the resolution of several other bugs. Therefore I really would like to see the authentication redesign committed rather sooner than later provided no conceptual flaws are found. Minor issues may later be dealt with smaller incremental patches. Oleg I can perfectly understand that. I was in the same situation a year (or more?) ago when I was maintaining the Proxy patch :-) I will review your patch also in respect to its usability for the new local proxy test code. Odi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Next Release?
Hi, When are u planning to make the next release?? srini -- Srinivas Vemula +91 40 23547826- Ext 201 Associate Consultant +91 40 23541447 (Fax) Mensamind+91 98497-42720 (Mobile) Hyderabad India http://www.mensamind.com DISCLAIMER The information contained in this e-mail is confidential and intended for the named recipient(s) only. If you are not an intended recipient of this email you must not copy, distribute or take any further action in reliance on it. You should delete it and notify the sender immediately. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: DO NOT REPLY [Bug 25529] Redesign of HTTP authentication framework
Odi, I would very much appreciate that. It is a fairly large patch, difficult to maintain up-to-date as the CVS content mutates. It block the resolution of several other bugs. Therefore I really would like to see the authentication redesign committed rather sooner than later provided no conceptual flaws are found. Minor issues may later be dealt with smaller incremental patches. Oleg -Original Message- From: Ortwin Glück [mailto:[EMAIL PROTECTED] Sent: Thursday, January 08, 2004 09:50 To: Commons HttpClient Project Subject: Re: DO NOT REPLY [Bug 25529] Redesign of HTTP authentication framework Kalnichevski, Oleg wrote: > Has anyone looked at this one? Any feedback so far? > > Oleg I am definitely going to have a look until next week. I can say more then. Odi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 25529] Redesign of HTTP authentication framework
Kalnichevski, Oleg wrote: Has anyone looked at this one? Any feedback so far? Oleg I am definitely going to have a look until next week. I can say more then. Odi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
