> > Hi,
> >
> > I'd like to use the Commons HttpClient component for Cactus v2. I'm
trying
> > to use it but it seems it doesn't currently support adding several
values
> > for a given Http Parameter or a given HTTP header (see
> HttpMethodBase.java).
> > However I seem to remember that it is allowed by the RFC (can't remember
> the
> > number, sorry). This behaviour is what I already have in Cactus v1
(using
> > standard HttpURLConnection) so I would hate to loose this feature in the
> v2
> > ...
> >
> > Do you agree to include the support for multi-valued parameters and
> headers
> > ? Also, what do you think about renaming the setHeader() and
> setParameter()
> > to addHeader() and addParameter() instead, as set is a bit misleading
(and
> > less standard) when you can call several times the same method ?
> >
> > >>>>>>>>>>>>
> >
> > We can add that, but you're not allowed to change the API ;-)
> >
>
> That's my biggest problem with HttpClient as it is ... I'd really like to
> use it. However, it currently lacks a lot of support from the RFCs. We can
> see that is was designed and used for a given task at hand and not as a
> generic component that could be used in lots of different scenarios (this
is
> not a rebuke, it is completely normal seen the history of it). I just hope
> that we will be able to change that and make it a fully generic and
> RFC-compliant framework in the future.
I definitely don't agree on the genericity. What do you think is not generic
in the design ?
Also, there's a lot of features missing (the headers is a valid point, but
you can easily implement that by *adding* a few methods; besides, I'll need
the feature for DASL).
> hum... I understand that you want to release a 1.0 version that you could
> use (with little change) in Slide. My problem is that I need it now ...
Here
> is what I propose :
> - you release a 1.0 version. When ?
> - I continue to use the standard HttpURLConnection from the JDK which in
the
> end is probably quite enough for my purpose (at the current time, the
amount
> of code to use HttpClient is about the same I have write when using
> HttpURLConnection directly). My rationale for using HttpClient was the
> following : as time goes on, I'll want to add support for other
HTTP-related
> features (like supporting the PUT HTTP operation, ....) and RFC compliance
> and my code will get bigger and bigger in that area. Having a library that
> implements it thoroughly is a pain-saver ...
>
> FYI, Jigsaw has both a server side and full implementation of the HTTP API
> on the client side (packages org.w3c.www.*), including DAV support and
> others (The "main" class is the HttpManager, see
>
http://jigsaw.w3.org/Doc/Programmer/api/org/w3c/www/protocol/http/HttpManage
> r.html). However, it seems it is _very_ badly documented on their web
site,
> all their docs only mention Jigsaw as a server (packages org.w3c.jigsaw.*)
> ... It is a pity they have not externalized the client side API in a
> dedicated project ... However it seems all the client side live in the
> org.w3c.www.* packages and does not depend on anything else so it is very
> easy to extract it.
I looked at it, and I don't really like the design the API.
I'm not too excited by the idea of making the API look like that.
Remy
