hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Cook <den...@bevocal.com>
Subject RE: [REMINDER] HttpClient IRC event - irc log
Date Fri, 28 Feb 2003 01:51:59 GMT
Here is the complete session:

Session Start: Thu Feb 27 12:01:16 2003
Session Ident: #httpclient
* Now talking in #httpclient
* Topic is 'Jakarta Commons HttpClient discussion 20:00-22:00 UTC Thursday
Feb 27'
* Set by Jandalf on Wed Feb 26 13:30:33
<LLyric> (Offtopic) Oh, if any of you use windows, TortoiseCVS is getting
really good...
<LLyric> Woop!  Oleg fixed the poll for response?
<LLyric> Great.
<LLyric> But how come we can't just use a blocking read?
<AJOfOZ> I believe we need a timeout.
<LLyric> Sure, but read has a timeout
<Oleg> Correction. I just make the request thread pause for a while when
<Oleg> LLyric, please elaborate. I did not quite get it
* Jandalf is back
<Jandalf> Yo all
<Oleg> Hey, The Chairman is back!!!
<LLyric> Oleg: is the reader in a different thread to the thread polling for
response ready?
<Oleg> The whole point is that I see the use of an extra thread as an
overkill in this particular situation
<Jandalf> Thanks for coming.  Smaller than expected turnout ...
<LLyric> Oleg: I was thinking out loud ; the InputStream is actually from a
Socket, and Socket has a setSoTimeout; so I was wondering why we were
polling at all.
* AJOfOZ has quit IRC (leguin.freenode.net irc.freenode.net)
* MikeB has joined #httpclient
<Jandalf> Adrian appears to be having some issues with his client ...
<MikeB> this is my first IRC
<Jandalf> No problem.  Just type to talk!
<Jandalf> Woa, I have 28 unread HttpClient emails~
<Oleg> OK. I see your point. I'll look into it. Feel free to contribute a
patch, though. 
* AJOfOZ has joined #httpclient
<Jandalf> AJOfOZ: Still have deamons in your irc client?
<AJOfOZ> Nope, the australian server died.
<AJOfOZ> or split from the rest of the world anyway.
<AJOfOZ> Suddenly I was all alone...
<Jandalf> That Optus network is CRAP!
<AJOfOZ> Optus is generally much more reliable than Telstra.
<AJOfOZ> Unfortunately I think I'm dependant on both to connect to the Aus
IRC servers.
<Jandalf> That Telstra network is CRAP!
<Jandalf> Thats CRAP!
<AJOfOZ> heh.
* Eric has joined #httpclient
<Jandalf> So, Oleg and LLyric have been discussing polling and blocking
reads ...
<Jandalf> Is there still more to say on that?
* LLyric shrugs. Nope, we'll talk on list.
<Jandalf> Somewhere deep in middle earth a gathering of the great elks
* LLyric is working on a TestCase for the http-continue bug
<AJOfOZ> That's sounds awfully familiar...
<LLyric> And checking current CVS with the test war
<Jandalf> An Elk is kinda like a moose, I think that was supposed to be
Ents, like walking trees.
<AJOfOZ> oops, yeah that was it.
<Jandalf> Cool interlude anyway.
<Jandalf> I had posted a tenative schedule:
<Jandalf> - Middle Earth nicks
<Jandalf> > - Redirect architecture
<Jandalf> > - Branch strategy and timing
<Jandalf> > - URI subproject
<Jandalf> > - general@apache and IRC
<Jandalf> > - anything else
<Jandalf> Anything else to discuss?
<LLyric> The Big Refactor?
<LLyric> Related to #3 I guess
<Oleg> How about women?
<Jandalf> How about CRAP?
<Jandalf> Note to self: use the word CRAP as many times as possible today.
<Oleg> ;-)
<Jandalf> So about nicks.
<Jandalf> I just wanted to clarify who people were, and assert that nicks
are just for fun.  Its not an elitist thing.
<Jandalf> OK.  Thats CRAP.  Lets move on.
<Jandalf> Redirect architecture
<Jandalf> Or should we talk about girls?
* MikeB has quit IRC (Remote closed the connection)
<Oleg> I guess we have to agree on branching strategy first
<Oleg> We already have defections ;-)
<AJOfOZ> I guess the key questions are: 1. How important is cross-host
<AJOfOZ> 2. How much will the reorg destabalise the code?
* MikeB has joined #httpclient
<AJOfOZ> 3. How much inconvenience will the behavioural changes have.
<MikeB> My connection seems to be quite bad.  I may keep disconnecting.
<AJOfOZ> I don't think 3 is really an issue since most people will be using
HttpClient and we can add a couple of methods to let Laura Werner use it
successfully as well.
<Jandalf> 1) I'm kinka amazed that cross host redirects has been absent for
so long.  Its seems glaring.
<Oleg> The main concern is that there are folks who currently do not use
HttpClient at all. They will be affected most
<Jandalf> MikeB: hang in there buddy!
<Jandalf> And this is my biggest pet peeve with HttpClient: the many modes
of use.
<Jandalf> Basicly everything is public and there are many ways to do one
think (make a Http request).
<AJOfOZ> I am also concerned that 2.1 is going to have major API changes
straight after everyone just rewrote for 2.0.
<Eric> Never used IRC before, so forgive me if I confuse you.  As to
redirect architecture, I liked Oleg's original approach.
<Jandalf> Me too.  I was looking at the release guidelines, and really major
changes like proposed by Oleg would be a major release.  ie 3.0
<MikeB> Seems like we need to decide if we want to release something stable
soon or if we want to do it right and take longer.
<Eric> Given that we've also had someone reporting problems with reconnects
over HTTPS, it seems like we should be tackling the retry issue anyway.
<MikeB> True that's a big one.  Http through a proxy.
<MikeB> Https through a proxy that is.
<Jandalf> I would like to say do it right, but it has been like 16 months
since HttpClient's last release.  Thats not our fault, but is the reality of
the situation.
<AJOfOZ> I'm actually leaning towards doing the refactoring now just so that
the API stabalises for the future.
<MikeB> Yes, bad starting point.
<AJOfOZ> But I share Jandalf's concern about not having a release - we have
been shipping a CVS nightly for a few months now.
<Jandalf> At least there are some alphas for people to work with now.  No
more reccomending users take a CVS snapshot.
<Eric> Yes, but it is usable now with the various Alpha releases.  I think
we can successfully make the changes without a huge change in the API,
although perhaps with significant deprecations.
<Oleg> I'd say shipping a 2.0 release and the next day breaking the API is
almost as bad
<Oleg> Chances are needed no matter how dearly we would like to avoid them
<Jandalf> Its true that because the last offical release was 1.0 (a lifetime
ago) we do have interface flexibility now.
<MikeB> seems like we almost need 2 dev branches.  one to fix 2.0 and one to
do it all correctly (3.0)
<Jandalf> But because people have been using cvs snapshots for so long and
now alphas, we do have some responsibility to users.
<AJOfOZ> But do we have the resources to maintain 2 dev branches?
<Eric> I think we should avoid branching as long as possible.
<MikeB> Probably not, but thought I would bring it up.
<Oleg> I'd rather spend my time on helping people out with rewriting their
code, than tracking down some obscure bugs
<MikeB> Good point Oleg.
<LLyric> Oops, back
<Eric> Are there any major issues out there for 2.0 besides the cross-host
redirect and https+proxy retry?  Shouldn't we just tackle this issue?
<Jandalf> I'm torn over a refactoring branch now, or wait for 2.0 release.
<Jandalf> There are still 12 outstanding bugs for Beta1, but most are small
time.  Very little major stuff.
<Eric> Rather than refactor, we could put experimental things in an
experimental CVS branch, rather than branching?
<dcook> Acting as proxy for Laura (looks like she won't be present)
<Jandalf> Eric: true, its a possibility.
<dcook> I would have to say the sooner the restructing is done, the better
off we would be.
<MikeB> Why are we wary of branching?
<dcook> With the 2.0 release we would still be working around the
* MikeB has quit IRC (Remote closed the connection)
<Jandalf> dcook: so you say all major forseeable changes should be done
before 2.0 is released?
* MikeB has joined #httpclient
<Jandalf> MikeB: branching early adds extra overhead, merging fixes and
<dcook> if there is going a significant delay after the 2.0 release to the
restructure then I would say put it in now.  
<AJOfOZ> I think Laura had mentioned that HttpClient should become more
flexible.  The new method she suggested didn't look too difficult to
implement and then anyone in her situation (we had another one appear a
couple of days back) would be able to use HttpClient instead of writing
their own.
<MikeB> ...back,  true but it's not that bad
<dcook> I think a lot of work was done with the alpha1
<Jandalf> dcook: seeing that this is open source development, the timelines
are always unforseeable.
<dcook> the beta could also last a while
<LLyric> Why not just branch the "old" code, then do the refactoring on
<MikeB> yes
<LLyric> Applying patches to the stable branch as necessary.
<Jandalf> But the question is: what to release?
<dcook> what is left from this alpha to get to beta?
<AJOfOZ> My concern with that is that it would mean a) no cross-host
redirects in 2.0, b) possible remaining problems with reconnects over HTTPS
and c) a big refactoring straight after the 2.0 release was supposed to be
the big refactoring.
<Jandalf> If we are talking of the refactoring of redirects as a feature,
then mabye this should be after 2.0
<LLyric> How compatible is the current stuff with the last release?  What
version do most end-users use?
<Jandalf> But if we are talking of the refactoring as a bugfix, then it
should be in 2.0 as a point of quality.
<AJOfOZ> There is essentially no backwards compatibility with 1.0 (or even
to half way through development) but a lot of people are tracking nightlies
so we are basically in a state of constant release.
<MikeB> I think most people are using alpha1 or a recent CVS
* LLyric nods
<dcook> while we have been monitoring the daily changes, for any project we
would only go with the binary release
<LLyric> Problem is, since we don't work on a branch, the quality of HEAD is
very variable...
<Jandalf> The opensource users would likely track CVS latest and greatest,
where the corporate users would take releases only.
<Jandalf> So we have two very different sets of users of HttpClient OS and
<MikeB> agree with llyric, we're still  doing misc. development on 2.0 which
is causing problems
<AJOfOZ> It is causing problems, but I wouldn't expect development to stop
until we hit beta (which is soon, but not quite yet).
<Jandalf> This was not too bad in the past, but you are right, everyone
working off HEAD is starting to be an issue, particularly for people
tracking HEAD.
<Jandalf> That said, people really should not be tracking head anyway.
<MikeB> there is nothing else to track
* LLyric chases required bugfixes, which means that I have to use HEAD most
of the time...
<LLyric> Otherwise there's too many bugs.
<Jandalf> Only now releases could be followed.
<MikeB> true that helps, but the releases still have some big problems.
<Jandalf> When we do get a 2.0 releases, minor bugfixes (2.0.x) could go out
the door as often as necessisary. 
<dcook> All releases have problems. Can't the known issues for a release
just be published with the release.
<Jandalf> dcook: Yes, and then fixed and released again ASAP.
<dcook> At some point in a release cycle you just have to say that is
enough, or it will never go out.
<Jandalf> dcook: This is a good point.  And after 15 months, we need a
release.  The problem is that we also want to guarntee some stability.
* LLyric nods
<Eric> How about we try to follow through with Oleg's patch (without
actually committing it) - to see if we can make the changes relatively
stable, rather than worry about it in the absence of a patch?
<LLyric> (Offtopic) BTW, is "ant test-local" supposed to be 100% at the
<Oleg> Both approaches have procs & cons. Fixing stuff that is broken
creates short-term problems, but guarantees long-term viability. That's my
take on it
<Jandalf> The problem is the users that use the methods directly and depend
on it will be shocked if all redirect funcitonality goes into HttpClient
* MikeB has quit IRC (Remote closed the connection)
<Jandalf> And there are users like this: dcook and Slide as examples.
<Eric> All else being equal, I would be OK with fixing the minor issues, and
leaving the redirect/proxy+https+retry problem to a 2.1 release, and simply
declare victory for 2.0
<AJOfOZ> I thought Slide used HttpClient?  They used to...
* MikeB has joined #httpclient
<Jandalf> I have seen some of there code that calls method.execute()
directly.  There may be a httpclient object in there too ...
<dcook> I have been monitoring for quite awhile now, and it seems that you
are into alot of corner cases. These tend to chew up a lot of time and point
out all the gremlins hiding in the design. If I were voting I would say cut
2.0 and move on the restructe in 2.1 (or 3.0)
<Eric> I did write up a proposal for how we could keep the old redirect on
the httpmethodbase, but also move the functionality to HttpClient.  I think
it might just be a matter of some internal gymnastics.  Ugly, but it would
allow us to move forward, and then deprecate the functionality for 2.2/3.0.
<MikeB> yes
<AJOfOZ> The trouble is that it still destabalises the code at a time when
we desperately need it to stabalise.
<Jandalf> Eric: I hear you.  But am a little concerned over complexity. (and
<dcook> so branch 2.0, stabilize it and push on in HEAD
<Oleg> I am not quite comfortable with this idea. If we do it, we should do
it right
<AJOfOZ> I think it would be easy enough to move the redirect/retry stuff to
HttpClient and make it easy for those using the  methods directly to adapt
to it, but we need to be stable.
<AJOfOZ> We almost need a 1.99 for those who can't wait for 2.0.
<Eric> Like I said, why not just declare victory on 2.0?  Software is never
perfect, why should this be different?
<MikeB> Sounds like we're all perfectionists:)
<Jandalf> AJOfOZ: we should be trying to encourage people to use HttpClient
directly with features.
<AJOfOZ> Agreed, that's pretty much my plan on how to make it easy to adapt.
<Jandalf> AJOfOZ: very reasonable.
<MikeB> Features like HTTPS with proxy and site redirects.
<Jandalf> The bottom line is, we can'
<dcook> Never used a piece of software that did not have some problem.  That
is the benefit of OS, I find it, I fix it, then send the fix back.
<LLyric> Also, if it's not done already, the test-cases / sample code should
*only* do it in the "correct" manner.
<Oleg> Eric: Victory is a relative concept, indeed ;-). I see sense in what
you are saying
<Jandalf> t break current direct method users code.  So pulling the current
limited redirect logic out of HttpMethodBase for 2.0 is out.
<Eric> Well maybe we don't pull it out - we just deprecate its use there.
<Jandalf> Eric: this is a possibility that works, but has complexity and
stability concerns.
<Jandalf> If we are talkning cross host redirects as a feature, I think this
should be pushed untill after 2.0.
<Jandalf> But is it ONLY a feature?
<Eric> I agree, but that is why we have our test cases, a bunch of people
dedicated to getting it right, and bunches of spare time on our hands (NOT!)
<AJOfOZ> It's a *big* feature, but it is just a feature.
<MikeB> Its a feature
<Eric> I think yes, it is only a feature.
<MikeB> back in a few
<Jandalf> Oleg?  Feature/No feature.
<Jandalf> ping Oleg
<Jandalf> Earth to Oleg ... come in Oleg.
<MikeB> What about https+proxy.  Is reusing these connections a feature.  We
can fix this by not allowing the connection to be reused.
<AJOfOZ> Connection reuse is mostly a feature, though I believe it's
actually in the HTTP/1.1 standard.
<Oleg> Baikanur, baikanur.... Respond!
<Oleg> Sorry. I got comletely lost here
<Oleg> Ok. I think that cross-site redirect is no hard feature
<Jandalf> So based on the concensus that cross site redirects is a feature,
and potentially disruptive, it should NOT go into 2.0.
* MikeB has quit IRC (Remote closed the connection)
<Oleg> Any decent developer can quickly whip it up cross-ste redicects on
top of HttpClient
<Jandalf> Right.
<AJOfOZ> Oleg: True.  Perhaps we should include example code on the web
<Oleg> Nema problema
* MikeB has joined #httpclient
<Oleg> I'd say let's close outstanding bugs, release 2.0 without cross-site
redicrects and more on with development
<Jandalf> Oleg: I agree.
<MikeB> yes
<AJOfOZ> Sounds like a good plan.  I've added creating docs for handling
cross-host redirects to my plan for the website docs.
<Eric> So we hack together a fix for the retry on proxy connections?
<MikeB> other than closing them?
<Oleg> How uglu is that gonna be?
<MikeB> UGLY
<Oleg> hmmm. 
* LLyric , for example, has implemented cross-site redirects. No problem.
<AJOfOZ> LLyric, would you be able to extract a simple example of how to do
<MikeB> I think we can duplicate the Connect code in HttpMEthodBase.  It
will not be pretty but it should work.
<Oleg> Oh, man...
<Eric> Or better yet, wrap the open connection logic up behind an interface,
then pass that interface down to HttpMethodBase.
<AJOfOZ> So this issue is specific to HTTPS, proxies and retrying or is
HTTPS not involved?
<Jandalf> Eric: as far as vision goes, should proxy retry be done in
HttpClient or in HttpMethod?
* LLyric basically just caught the http status code, recycled the method,
and resent it to the right place
<MikeB> It's just HTTPS
<Eric> I believe it is the combination of https+proxy.
<MikeB> yes HTTPS+Proxy
<MikeB> Another option might be to push the ConnectMethod logic into the
<Eric> Ugh!
<Jandalf> Like dcook mentioned, this is a corner case.  Its good to
highlight arch problems, but is this better done with the retry logic in
HttpClient (post 2.0)
<MikeB> Agreed, but we need to do it for 2.0 as well, yes?
<AJOfOZ> Agreed, what's the simplest way to make HTTPS and proxies reliable?
<Eric> I'd almost agree that it is a corner case, except connection timeout
while using https+proxy seems to be a fairly normal scenario, so we have to
work around it.
<MikeB> don't allow reuse
<Jandalf> MikeB: Dunno.  You tell me.
<AJOfOZ> The down side of that is slower performance because of the connect
overhead and not following the HTTP1.1 standard to the letter (reuse
connections by default).
<MikeB> Yes, just being a smart ass.  That's the easiest solution.  After
that I think we would either need to push the logic into HttpMethodBase or
as Eric say use a wrapper of some sort.
<Oleg> I would opt for the simplest solution for 2.0 and would do it right
in post 2.0
<AJOfOZ> That's what I'm looking at as well Oleg (hence the basic
<Jandalf> Oleg: Agreed, even if the simple solution is not efficient, as
long as its reliable.
<AJOfOZ> Have I missed any other disadvantages?
<Oleg> be back in 10 min
<MikeB> No, just performance I think.  Should we find out how bad the
performance would be?
<AJOfOZ> It would match the performance of HTTP1.0 wouldn't it?
<AJOfOZ> but yes we probably should investigate that.
<Jandalf> MikeB: need a patch for that.
<MikeB> Can do.  We only need to change shouldCloseConnection()
<Eric> And provide a test case of course :-)
<MikeB> Do we have any good ideas for tests?  Something real world?
* MikeB has quit IRC (Remote closed the connection)
<Jandalf> (MikeB is now cursing his connection)
<AJOfOZ> heh.
<AJOfOZ> Who was it that reported the problem?
* MikeB has joined #httpclient
<Eric> I've been trying to think of a good external web site.  Perhaps a
commercial web site like etrade.
<AJOfOZ> You'd also need a proxy that supports HTTPS.
<Eric> The reporter is Jani Mattsson.
<Jandalf> As long as they don's sue us for a DDOS attack.
<MikeB> Minor testing only.
<Eric> Yeah, that is what you say.
<MikeB> Does anyone have a server locally that would suffice?
<AJOfOZ> Actually, I can provide one Ithink...
<Jandalf> 1000 httpclient users running "ant test-etrade" simultaenously.
<AJOfOZ> The proxy I can't provide but I can set up one locally to test from
time to time.
<MikeB> how many users do we have?
<Jandalf> MikeB: of HttpClient?
<MikeB> yes
<Jandalf> About 20 organizations that will admit to it.
<MikeB> I usually run squid locally for testing with a proxy.
<MikeB> Are there stats on distribution downloads?
* LLyric uses it for several of his clients
<AJOfOZ> Yep, I can set up a secure server for low bandwidth tests but it
will take a few days (my hosting providers service is pretty poor).
<Jandalf> MikeB: they are mirrored, so no.
<Jandalf> MikeB: there are over 130 subscribers to the httpclient mailing
<LLyric> I guess all of them probably use it.
<MikeB> Maybe we should stick with etrade and just make sure only one person
does it.  That way it won't be distributed, only DOS:)
<LLyric> Fire it at any big site, they'll never notice.
<LLyric> Eg: slashdot, cnn.com, bbc.co.uk, etc
<AJOfOZ> we create a component that sells to hundreds of developers world
wide, so the distribution of HttpClient should be pretty big. :)
<AJOfOZ> Sourceforge use SSL heavily.
<MikeB> We would only be doing a couple of hundred connects.  You are
probably right, they would not notice/care.
* LLyric excercises httpclient pretty thoroughly - dozens of client
connections per machine, 6-8 machines, testing POST/PUT/GET/DELE/HEAD....
<Jandalf> So we have come to an agreement that 2.0 should be released with
no new features, just quality control and stability for current users.
<Jandalf> We need to talk about what comes after that.  2.1, 3.0, branching
<MikeB> Yes, unless killing SSL+PROXY reuse is really slow.
<MikeB> It would have to be really bad.
<LLyric> SSL is slowish anyway, they won't notice a little extra :)
<Jandalf> For 3.0, we can have a LOT of flexibility on what is changed,
anything really.
<AJOfOZ> Maybe we schedule the refactoring of HttpMethodBase as a main
feature in 3.0 and include a note to this effect in the JavaDoc for this
<AJOfOZ> That would encourage people not to start using it directly.
<Jandalf> But 2.1 should still be geared to 2.0 users.  ie: no change in
paradigm, as consistant as possible.  Anything big could go 3.0
* LLyric nods
<LLyric> Absolutely
<Eric> Yes
<LLyric> People expect sub-releases to be reasonably compatible
<AJOfOZ> We would of course then need to add the flexibility to HttpClient
that they need.
<MikeB> What would be in 2.1
<Jandalf> MikeB: I don't know.  
<LLyric> Bug fixes, minor updates, etc.
<LLyric> Ditto 2.2 etc.
<LLyric> Maintenence releases
<MikeB> Any features
<Jandalf> If its just maintaince and bug fixes, that can just be 2.0.x
<LLyric> Maybe, if people wanted them, and it was worth backporting from the
3.x code
<MikeB> Yes, if there are no features it should be a 2.0.X.
<Oleg> I am back
<Eric> (offtopic) I'm going to sign off.  Could someone capture the text of
the whole discussion and post it back to the mailing list, so that everyone
can see the discussion?
<Jandalf> 2.1 would have to have some features in it to be justified as a
minor release.
<AJOfOZ> Eric: I'm logging it and will take care of that.
<Jandalf> Eric: I'm doing that.
<Eric> Excellent - bye.
* MikeB has quit IRC (Remote closed the connection)
<AJOfOZ> I'll leave it to Jandalf then. :)
* Eric has quit IRC
* MikeB has joined #httpclient
<AJOfOZ> There's actually quite a few bugs slated for the 2.1 release
already (mostly new feature bugs).
<dcook> I would suggest that new features wait until after the interface
<Jandalf> The other question is when to branch 2.0, 2.1 and 3.0
<MikeB> I think 2.0 soon.  There are many features that are dying to get in
to 3.0.
<AJOfOZ> I'd like to see 2.0 beta 1 get out before we branch at least.  That
way there's only bug fixes and docs left before 2.0 final.
<Jandalf> dcook: I agree, but if 3.0 is where the action is, and someone
really wants a feature in 2.x, then thats fine (particularly if they want to
provide a patch!)
<Jandalf> AJOfOZ: Yes.  I think we should branch as late as possible.  
<dcook> But even if a patch was provided, rolling out a release takes
significant effort.
<AJOfOZ> But the 2.0 branch would be constantly stable so taking a nightly
from there won't be so bad.
<AJOfOZ> And releases would be regular enough that there'd be a final
release ready before most projects using HttpClient ship.
<AJOfOZ> Never perfect but close enough.
<MikeB> I think that's the argument for branching soon.  It will make 2.0
more stable I think.
<AJOfOZ> For the record: Inadequate HTTP proxy server support in HttpClient.
is scheduled for beta 2.
<Jandalf> MikeB: But I want to avoid everyone working on 3.0 before 2.0 is
even released yet.
<MikeB> True.  There might be a mass exodus.
<AJOfOZ> Once we get beta 1 out the only thing left is bug fixes and docs.
So a maass exodus won't hurt as much. :)
<Jandalf> But at the same time I don't want to hold anyone back from
"scratching an itch"
<MikeB> Yes, I think some are getting anxious.
<Jandalf> So how about we say 3.0 will branch just after 2.0 beta1 is
<AJOfOZ> +1
<MikeB> +1
<Oleg> +1
<MikeB> So when is 2.0b1?
<AJOfOZ> There's about 14 bugs in bugzilla scheduled for beta 1.
<Jandalf> I'll takes those votes as agreement, but actual voting will still
have to be done on the mailing list.
<AJOfOZ> A couple of them look fixed though.
<AJOfOZ> Jandalf: Good to hear. :)
<MikeB> Yes, some of them are questionable.
<Jandalf> I'm Apache Compliant.
<AJOfOZ> hehehe
<Jandalf> Bugs: Yes, really Beta 1 is not too far away.  Some of those bugs
are less than one hour of work.
<Jandalf> Most, in fact.
<Oleg> I wish it was the case with 100-continue thingie. I can't even
reproduce it. But it appears to be the only nasty one
<MikeB> It seems quite nasty.
<Jandalf> Right.  That is a difficult one.
<MikeB> Does is happen in HTTPS or HTTPS+Proxy
<Oleg> Jandalf, I need to get going soon. Anything important left to
<Jandalf> One thing.
<Oleg> I believe just HTTPS
<Oleg> Go ahead
<Jandalf> I had a plan to rip out the URI classes into a commons subproject.
<Oleg> Oh. Please do so
<MikeB> Would this be a new sandbox project?
<Jandalf> Its motivated by 1) the code is terrible 2) it is useful beyond
httpclient 3) the code is terrible.
<Jandalf> MikeB: could be, might be able to jump right to commons status, as
its meets all the requirements for new projects.
<MikeB> Other than reasons 1 and 3.
<Jandalf> He he.
<MikeB> I should go soon as well.
<Jandalf> License, stability, contributors ...
<Oleg> Greater visibility should help, though. It's been one man show for
too long
<Jandalf> So 3.0 will not have a URI class is what this means.
<Jandalf> But we will have it as a dependancy.
<Oleg> Amen
<Jandalf> Before you all go,
<Jandalf> I'm having some trouble understanding the new PMC structure for
<Jandalf> But I am working on it.  They are doing some things I don't agree
with.  There seems to be some strange sentiment as well dealing with ...
<MikeB> Unique people?
<Oleg> How does that affect us?
<Jandalf> Like the negative feelings towards IRC, because its not email, not
the "Apache Way"
<MikeB> Conformity.
<Jandalf> If we do nothing, it could be that ONLY PMC members get to vote on
<Jandalf> It takes control out of our hands.
* MikeB has quit IRC (Remote closed the connection)
<AJOfOZ> Jandalf: Is the reorg list open to non-committers now?  I
originally followed the discussions and was cut out when it moved from
community to the committers only reorg.
<Jandalf> But all committers can be PMC members, so we can get it back.  It
just means that we have to be involved.
<Jandalf> Dunno.
* MikeB has joined #httpclient
<Jandalf> The information is scant on the reorg, it is changing very quick.
<Jandalf> I feel a little coerced into being a PMC member, when in fact I'm
just happy doing what I'm doing.
<MikeB> What are the down sides of becoming one?
<Jandalf> More administration, less code (as far as I can tell)
<MikeB> Who would you be administering other than HttpClient?
<Jandalf> As you may have noticed, I mostly do admin now already, and hardly
every get to code anymore.
<Jandalf> I don't know, its just this general overall responsibility that
comes with PMC status.  
<Jandalf> I can barely keep up with you guys as it is <grin>
<AJOfOZ> The PMC is intended to oversee all of the project they cover (ie:
all of Jakarta).  That load is spread over all the PMC members though.
<Jandalf> Yes, but then I'd (we'd) have to attend PMC meetings (online),
watch the PMC list yadda yadda yadda.
<MikeB> How many PMC people would there be then?  Is there going to be an
explosion of jakarta projects in the near future?
<Jandalf> I just wanted to say that Apache is changing, and I'm concerned
about it, but not currently in much of a position to do anything about it
(but an working on that).
<AJOfOZ> It sounds like it might be a good idea for any HttpClient
committers who have the time to subscribe to the reorg list and speak up
about their concerns etc.
<Jandalf> According to Sam, all committers should be PMC members.  Which
sounds silly, unachieveable, and undesirable to me.
<MikeB> yes, why have PMC if all committers are PMC.
<Jandalf> AJOfOZ: Yes, absolutely.  I have no special part in Apache.
<Jandalf> MikeB: Dunno, but thats the "vision".
<MikeB> Well.  I need to go.  I'll check out the reorg list and see what's
been going on.
<Jandalf> Groovy.
<AJOfOZ> Yep, time for breakfast methinks.
<MikeB> good chat all.  talk with you later.
<AJOfOZ> Thanks for organising this Jandalf, we got a lot decided.
<Oleg> Guys, got to be going.
<Jandalf> Thanks to everyone for hanging out here for a while.
* MikeB has quit IRC ("ChatZilla 0.8.13c [Mozilla rv:1.3b/20030210]")
<Jandalf> I'll post meeting minutes soon.
* Oleg has left #httpclient ("Client Exiting")
<Jandalf> Bye for now!
* AJOfOZ has quit IRC ("So long....")
* Jandalf has quit IRC ("using sirc version 2.211+KSIRC/1.2.1")
* Disconnected
Session Close: Thu Feb 27 14:09:09 2003

Dennis Cook
BeVocal, Inc.
tel:  650-641-1424
fax: 650-210-9275

-----Original Message-----
From: Jeffrey Dever [mailto:jsdever@sympatico.ca]
Sent: Thursday, February 27, 2003 5:47 PM
To: Commons HttpClient Project
Subject: Re: [REMINDER] HttpClient IRC event - irc log

The IRC session we had today went well.  Except that we only captured about
1/4 the discussion in a logfile (darn buffers).  The big topics of the day
were what to do about redirects and when to create development branches.

The general concensus was that 2.0 beta development should focus on
correctness without any disruptive changes to be released as a full version
as its ready.  The cross host redirects feature that Oleg provided a patch
for should be a *next* release item and includes such significant
restructuring that it would qualify for a 3.0 release change.  2.1 should
focus on compatability and stability over large scale change.  The 3.0
branch should be created after 2.0 reaches beta.

Of course all these points are up for discussion on the mailing list and
will have to come to a vote in accordance with Apache guidelines.

View raw message