> I must be missing something, but a Java version = multiple platforms > supported, unless you are referring to multiple platforms being > multiple languages.
Brad, et al I apologize for not having made myself clear enough. By multiple platforms I did not mean different operating systems. I meant to refer to different execution environments / APIs (JVM, CRL (.NET), ANSI C) > ... but considering the fact that HttpClient is an > implementation that is the conglomeration of several RFC's, I'd say > those additional RFC's (besides just the straight HTTP RFC) might > constitute sub-projects. A redesign of the architecture might make > things look more pluggable in the future. Of course, one may see Slide (WebDAV spec implementation) as a subproject of HttpClient. I bet, though, that Slide folks would beg to differ. To them HttpClient is just a utility layer. My point here, at the moment we lack (1) clear vision of how we would like to see HttpClient develop beyond its original purpose, (2) wider community of users (3) flexible architecture to foster such wider community of users. IMO, we win nothing by becoming a TLP. Instead we might end up with additional managerial overhead to bear. With our current scarce resources it may cause more harm than good. Let us roll up the sleeves and get down to business to make HttpClient 4.0 something worthy of Apache TLP. And one day we may find ourselves at the level where the promotion to TLP would be a matter of website redeployment. Cheers, Oleg -----Original Message----- From: Brad O'Hearne [mailto:[EMAIL PROTECTED] Sent: Monday, February 02, 2004 03:12 To: Commons HttpClient Project Cc: [EMAIL PROTECTED] Subject: Re: Promote HttpClient out of commons? Hey all, I'm new to the HttpClient mailing list, but here's a couple of newbie observations: > * Please correct me if I am wrong, but I always thought that TLPs were > supposed to support multiple platforms, hence their top level status. > Whereas I can certainly imagine HttpClient implemented in straight C or > C++ (or any other language), I just do not think we'll have enough > resources to actively develop anything but a Java version in the > foreseeable future I must be missing something, but a Java version = multiple platforms supported, unless you are referring to multiple platforms being multiple languages. > * I can hardly think of any subproject within HttpClient project. > Ability to host sub-project within a project is one of the primary > criteria for promoting a project to the top level. I do not think we > qualify I wouldn't be so hasty here. I think from a certain point of view, there are several sub-projects within HttpClient already. If you view HttpClient as one monolithic app (which it may well be now) then you have a point, but considering the fact that HttpClient is an implementation that is the conglomeration of several RFC's, I'd say those additional RFC's (besides just the straight HTTP RFC) might constitute sub-projects. A redesign of the architecture might make things look more pluggable in the future. > * As useful and feature rich HttpClient has become, let's face it, it's > not exactly a masterpiece of design elegancy. Being a TLP would make > HttpClient de facto Apache's official HTTP client. Frankly, I do not > think HttpClient in its present form deserves it. There's still lots to > be done before it possibly could. Masterpiece is a function of good design and maturation. I wouldn't worry too much about this -- there are many OSS projects (and proprietary ones) that rank low on the design elegancy scale. I guess as a newbie, my biggest question is, what are the disadvantages of promotion? As someone that recently had to complete an HTTP dependent project, I was very surprised at the woefully sparse number of helpful HTTP resources for the Java platform. Plenty of Google hits, few real meaty resources though. BradO --------------------------------------------------------------------- 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]
