You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Sander Striker <st...@apache.org> on 2001/09/26 23:14:05 UTC
[PROPOSAL] apr-client
Hi all,
I wish to propose a new library: apr-client.
It is basically a http client library. I see
a direct use for at least three projects:
- mod_proxy (which has most of the code in it),
- flood (to do more flexible testing, for example
with authentication, or even ssl client auth),
- subversion (which is currently using neon).
The library is going to be based on apr
and apr-util, and will have an optional dependency
on openssl (through a --with-ssl[=path] switch).
Features:
- sessions
- request building
- response parsing
- pipelining
- authentication support
- filters
- like ssl, gz, chunk
Callbacks will be used to drive events (like responses,
or the need for auth information).
The library should make heavy use of buckets/brigades,
I dare even say the request building is a thin wrapper
around those.
Requests supported should be all HTTP requests and
the DAV extensions.
The filters are a nice area for code reuse. The logic
for the client is ofcourse reversed, so we can have
a chunk filter on the request side and a dechunk on the
response side. This is just an example, replace
chunk/dechunk with gzip/unzip and you have another.
Same goes for ssl. This way the same code gets used in
multiple places which results in more extensive testing
of this code (which is a nice side effect).
You might ask yourself why the world would need yet
another http client library. Well, there seem to be
only two good ones: curl and neon. Curl is bloated
(has ftp, gopher, etc support and is more a general
network client library). Neon is good, but LGPL. Also,
it doesn't tie in nicely with apr (example is malloc/free
usage in it, which requires the user to malloc a chunk
of mem, fill it, pass it to neon which then frees it).
Well, this mail isn't the extensive description I wanted
to give*, but surely enough to get some feedback.
Sander
*) Am a bit distracted for some reason.
Re: [PROPOSAL] apr-client
Posted by Cliff Woolley <cl...@yahoo.com>.
On Wed, 26 Sep 2001, Greg Stein wrote:
> On Wed, Sep 26, 2001 at 11:14:05PM +0200, Sander Striker wrote:
> >
> > I wish to propose a new library: apr-client.
>
> btw, I'm +1 on all points in here.
+1 from me as well.
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: [PROPOSAL] apr-client
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Sep 26, 2001 at 11:14:05PM +0200, Sander Striker wrote:
> Hi all,
>
> I wish to propose a new library: apr-client.
btw, I'm +1 on all points in here. Sander and I talked about this quite a
bit last night over IRC. I'm hoping for a general go ahead, a creation of a
STATUS and or roadmap/design [for apr-client], and then being able to dump a
bunch of stuff in there.
Note that I believe a simple client could be scrapped together in a couple
evenings. It could support sessions, pipelining, multithread, brigades, and
filters. Adding the auth, SSL, and response [XML] parsing is the bulk of the
work.
>...
> The filters are a nice area for code reuse. The logic
> for the client is ofcourse reversed, so we can have
> a chunk filter on the request side and a dechunk on the
> response side. This is just an example, replace
> chunk/dechunk with gzip/unzip and you have another.
> Same goes for ssl. This way the same code gets used in
> multiple places which results in more extensive testing
> of this code (which is a nice side effect).
This would be good. However, I believe that it would probably be a good
amount of work to convert Apache's filters over to use apr-client's filters.
IMO, the latter's filter system will be a bit simply (in particular, NO
references to things like f->r and f->c). That implies a design difference
in the two systems.
So: excellent goal, but some recognition of the work is needed, too.
> You might ask yourself why the world would need yet
> another http client library. Well, there seem to be
> only two good ones: curl and neon. Curl is bloated
> (has ftp, gopher, etc support and is more a general
> network client library).
Agreed.
> Neon is good, but LGPL. Also,
> it doesn't tie in nicely with apr (example is malloc/free
> usage in it, which requires the user to malloc a chunk
> of mem, fill it, pass it to neon which then frees it).
The license is a big one for me (having apr-client and its ASF license means
we could replace proxy code with it; LGPL is a tougher decision for bundling
with ASF code). The integration isn't so big in my mind, but an APR-based
library would certainly eliminate a lot of dupliation (prolly 40% of neon
deals with stuff like allocation, strings, md5, base64, etc). And it would
also enhance portability. Also, Neon does not yet support pipelining (Joe
intends to, but it will be a big chunk of work). Those four items (license,
reduce dup, pipelining, portability) push me towards the +1 here.
That said: Neon is an excellent library. I do and would continue to
recommend it to people. I don't see SVN switching away from it for 1.0. But
post 1.0, picking up the pipelining and the tight APR integration will be
big win. [unless apr-client somehow managed to stabilize really fast]
I just think that the ASF projects could use it, and I think getting a
nicely licensed, fully capable client library would be great.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: [PROPOSAL] apr-client
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Sep 26, 2001 at 11:14:05PM +0200, Sander Striker wrote:
> Hi all,
>
> I wish to propose a new library: apr-client.
btw, I'm +1 on all points in here. Sander and I talked about this quite a
bit last night over IRC. I'm hoping for a general go ahead, a creation of a
STATUS and or roadmap/design [for apr-client], and then being able to dump a
bunch of stuff in there.
Note that I believe a simple client could be scrapped together in a couple
evenings. It could support sessions, pipelining, multithread, brigades, and
filters. Adding the auth, SSL, and response [XML] parsing is the bulk of the
work.
>...
> The filters are a nice area for code reuse. The logic
> for the client is ofcourse reversed, so we can have
> a chunk filter on the request side and a dechunk on the
> response side. This is just an example, replace
> chunk/dechunk with gzip/unzip and you have another.
> Same goes for ssl. This way the same code gets used in
> multiple places which results in more extensive testing
> of this code (which is a nice side effect).
This would be good. However, I believe that it would probably be a good
amount of work to convert Apache's filters over to use apr-client's filters.
IMO, the latter's filter system will be a bit simply (in particular, NO
references to things like f->r and f->c). That implies a design difference
in the two systems.
So: excellent goal, but some recognition of the work is needed, too.
> You might ask yourself why the world would need yet
> another http client library. Well, there seem to be
> only two good ones: curl and neon. Curl is bloated
> (has ftp, gopher, etc support and is more a general
> network client library).
Agreed.
> Neon is good, but LGPL. Also,
> it doesn't tie in nicely with apr (example is malloc/free
> usage in it, which requires the user to malloc a chunk
> of mem, fill it, pass it to neon which then frees it).
The license is a big one for me (having apr-client and its ASF license means
we could replace proxy code with it; LGPL is a tougher decision for bundling
with ASF code). The integration isn't so big in my mind, but an APR-based
library would certainly eliminate a lot of dupliation (prolly 40% of neon
deals with stuff like allocation, strings, md5, base64, etc). And it would
also enhance portability. Also, Neon does not yet support pipelining (Joe
intends to, but it will be a big chunk of work). Those four items (license,
reduce dup, pipelining, portability) push me towards the +1 here.
That said: Neon is an excellent library. I do and would continue to
recommend it to people. I don't see SVN switching away from it for 1.0. But
post 1.0, picking up the pipelining and the tight APR integration will be
big win. [unless apr-client somehow managed to stabilize really fast]
I just think that the ASF projects could use it, and I think getting a
nicely licensed, fully capable client library would be great.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: [PROPOSAL] apr-client
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Sep 26, 2001 at 07:36:50PM -0400, Cliff Woolley wrote:
> On Wed, 26 Sep 2001, Ryan Bloom wrote:
> > I agree with Roy about this. This doesn't really have anything to do
> > with creating a portability run-time. It really should be an httpd
> > sub-project.
>
> The only distinction I can make in my mind is library versus application.
> Around these here parts, when we think library, we (reflexively) think
> APR. I mean come on, most of the stuff in apr-util has nothing to do with
> portability.
Per my other post, that is the difference between "portability" and
"portable." All the APR* code is portable, and APR itself is the means for
portability.
:-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: [PROPOSAL] apr-client
Posted by Cliff Woolley <cl...@yahoo.com>.
On Wed, 26 Sep 2001, Ryan Bloom wrote:
> I agree with Roy about this. This doesn't really have anything to do
> with creating a portability run-time. It really should be an httpd
> sub-project.
The only distinction I can make in my mind is library versus application.
Around these here parts, when we think library, we (reflexively) think
APR. I mean come on, most of the stuff in apr-util has nothing to do with
portability. That's (mainly) why that stuff got put in apr-util and not
in APR. It didn't go in httpd because we wanted a library, which made us
think "the APR group should handle this". Whatever... I don't really care
where it goes. I just think it's a really good idea in general.
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: [PROPOSAL] apr-client
Posted by Ryan Bloom <rb...@covalent.net>.
On Wednesday 26 September 2001 04:22 pm, Roy T. Fielding wrote:
> > > And, in discussions with Roy, I think he was thinking a client
> > > library should be a part of httpd not APR. But, I don't care
> > > one way or another. -- justin
> >
> > Nah. This has utility outside of httpd. Specifically, Subversion is an
> > excellent candidate. I also know that Covalent has a similar library that
> > they use internally ("apua", I believe). So that is candidate #2. And
> > then you have your flood program for candidate #3. Of course, mod_proxy
> > would use it, but that can fall under Roy's httpd placement model.
> >
> > And then there are the ones we don't know about...
>
> All the more reason why it shouldn't be part of the Apache Portable Runtime
> project. If you want to create a new project for it, that's fine with me,
> but the only thing it has in common with APR is that it will use APR.
I agree with Roy about this. This doesn't really have anything to do with creating
a portability run-time. It really should be an httpd sub-project.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: [PROPOSAL] apr-client
Posted by Ryan Bloom <rb...@covalent.net>.
On Wednesday 26 September 2001 04:22 pm, Roy T. Fielding wrote:
> > > And, in discussions with Roy, I think he was thinking a client
> > > library should be a part of httpd not APR. But, I don't care
> > > one way or another. -- justin
> >
> > Nah. This has utility outside of httpd. Specifically, Subversion is an
> > excellent candidate. I also know that Covalent has a similar library that
> > they use internally ("apua", I believe). So that is candidate #2. And
> > then you have your flood program for candidate #3. Of course, mod_proxy
> > would use it, but that can fall under Roy's httpd placement model.
> >
> > And then there are the ones we don't know about...
>
> All the more reason why it shouldn't be part of the Apache Portable Runtime
> project. If you want to create a new project for it, that's fine with me,
> but the only thing it has in common with APR is that it will use APR.
I agree with Roy about this. This doesn't really have anything to do with creating
a portability run-time. It really should be an httpd sub-project.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: [PROPOSAL] apr-client
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
> Independent of httpd effectively means APR. I guess you could be an httpd
> subproject, but this has nothing to do with an HTTP server.
>
> [ there is no way the board would establish a new PMC for this, speaking as
> one of those board members :-) ]
I don't see why. I don't believe umbrella projects work for anything but
strict subsets of the PMC contributors. libapreq is an excellent example.
That is why APR was created as a separate PMC. If APR is not a subproject
of httpd, then I don't see any reason why a client project should be under
httpd.
In any case, the people wanting to set it up are going to have to set the
scope appropriately. Is it going to be limited to C? Use APR? What is
the interface?
I mean, if the interface is 100% APR dependent, then apr-client is as
good a name as any. I do want folks to keep in mind, though, that the
PMC structure is required to maintain oversight -- if the PMC responsible
for a cvs repository is not paying attention to the commits and releases
on that repository, then the code doen't belong in that PMC.
....Roy
Re: [PROPOSAL] apr-client
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
> Independent of httpd effectively means APR. I guess you could be an httpd
> subproject, but this has nothing to do with an HTTP server.
>
> [ there is no way the board would establish a new PMC for this, speaking as
> one of those board members :-) ]
I don't see why. I don't believe umbrella projects work for anything but
strict subsets of the PMC contributors. libapreq is an excellent example.
That is why APR was created as a separate PMC. If APR is not a subproject
of httpd, then I don't see any reason why a client project should be under
httpd.
In any case, the people wanting to set it up are going to have to set the
scope appropriately. Is it going to be limited to C? Use APR? What is
the interface?
I mean, if the interface is 100% APR dependent, then apr-client is as
good a name as any. I do want folks to keep in mind, though, that the
PMC structure is required to maintain oversight -- if the PMC responsible
for a cvs repository is not paying attention to the commits and releases
on that repository, then the code doen't belong in that PMC.
....Roy
Re: [PROPOSAL] apr-client
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Sep 26, 2001 at 04:15:30PM -0700, Aaron Bannert wrote:
> On Wed, Sep 26, 2001 at 03:52:18PM -0700, Greg Stein wrote:
> > > FWIW, flood in httpd-test already has 80% of what Sander suggested.
> >
> > Sander and I already talked about stealing code from flood and mod_proxy. :-)
>
> *ahem* ;)
>
> In all seriousness, I think we've already got most of the code we want.
> (Flood already does or can do some of the things Sander suggested).
Yup. However, (IMO) we would be started from the API and moving code to fit
that API. That is going to impose some difficulty in terms of stealing code,
but *any* prior work is going to ramp up apr-client quickly.
>...
> I have no problem with either the push or pull methods, but I wanted to
> make the point that flood could benefit from both request generation
> brigades/filters as well as response filtering.
Excellent.
It would be kind of cool for flood to get out of the socket business and
concentrate on its purposes: exercising, regression, and testing.
>...
> > Absolutely. That is why my previous email mentioned that I'd be happy to see
> > a directory / cvs module get started so a roadmap could be created. I would
> > want to see the API first, built from our expertise with the brigades and
> > filtering systems, and with a lot of the ideas embodied in Neon's APIs.
>
> +1
> (once we get it rolling we can move this kind of discussion there and
> start writing design docs)
I'm guessing that we would keep the discussion on the dev@apr list rather
than spinning up another list. But I have no strong opinions there.
>...
> I don't really care where it goes as long as it can be used independently
> of the core httpd source.
Independent of httpd effectively means APR. I guess you could be an httpd
subproject, but this has nothing to do with an HTTP server.
[ there is no way the board would establish a new PMC for this, speaking as
one of those board members :-) ]
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: [PROPOSAL] apr-client
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Sep 26, 2001 at 04:15:30PM -0700, Aaron Bannert wrote:
> On Wed, Sep 26, 2001 at 03:52:18PM -0700, Greg Stein wrote:
> > > FWIW, flood in httpd-test already has 80% of what Sander suggested.
> >
> > Sander and I already talked about stealing code from flood and mod_proxy. :-)
>
> *ahem* ;)
>
> In all seriousness, I think we've already got most of the code we want.
> (Flood already does or can do some of the things Sander suggested).
Yup. However, (IMO) we would be started from the API and moving code to fit
that API. That is going to impose some difficulty in terms of stealing code,
but *any* prior work is going to ramp up apr-client quickly.
>...
> I have no problem with either the push or pull methods, but I wanted to
> make the point that flood could benefit from both request generation
> brigades/filters as well as response filtering.
Excellent.
It would be kind of cool for flood to get out of the socket business and
concentrate on its purposes: exercising, regression, and testing.
>...
> > Absolutely. That is why my previous email mentioned that I'd be happy to see
> > a directory / cvs module get started so a roadmap could be created. I would
> > want to see the API first, built from our expertise with the brigades and
> > filtering systems, and with a lot of the ideas embodied in Neon's APIs.
>
> +1
> (once we get it rolling we can move this kind of discussion there and
> start writing design docs)
I'm guessing that we would keep the discussion on the dev@apr list rather
than spinning up another list. But I have no strong opinions there.
>...
> I don't really care where it goes as long as it can be used independently
> of the core httpd source.
Independent of httpd effectively means APR. I guess you could be an httpd
subproject, but this has nothing to do with an HTTP server.
[ there is no way the board would establish a new PMC for this, speaking as
one of those board members :-) ]
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: [PROPOSAL] apr-client
Posted by Aaron Bannert <aa...@clove.org>.
On Wed, Sep 26, 2001 at 03:52:18PM -0700, Greg Stein wrote:
> > FWIW, flood in httpd-test already has 80% of what Sander suggested.
>
> Sander and I already talked about stealing code from flood and mod_proxy. :-)
*ahem* ;)
In all seriousness, I think we've already got most of the code we want.
(Flood already does or can do some of the things Sander suggested).
> > The major thing it is missing is bucket/brigade/filters - which is
> > why I'm getting pissy about the API change because I want to move
> > flood to this. (It is also missing chunking and pipelining which I
> > was working on when I got interrupted when I saw how httpd handles
> > it and started to rewrite the input filtering.)
> >
> > The one thing I would change in Sander's proposal is that I detest
> > callbacks.
>
> It should not be hard to build it such that push or pull models could be
> used here.
>
> There are four points of push/pull:
>
> 1a) app pushes request into apr-client, which then transfers it onto the
> network. this is like the output filter chain of httpd.
>
> 1b) app gives a callback to apr-client, which it uses to pull data and
> deliver it to the network. this is similar to httpd pulling data via the
> input filter chain.
>
> 2a) apr-client pushes response to an app's callback
>
> 2b) app pulls response from apr-client as it becomes available
>
>
> An application can choose 1a or 1b, and 2a or 2b for how it handles the
> request/response process. The question boils down to "who is in control?" In
> 1a and 2b, the app is in control. In 1b and 2a, the library is in control
> (based on network conditions).
>
> When Sander mentioned callbacks, he was really referring to 2a. (that aspect
> came up in our conversation; we didn't discuss 1b much).
I have no problem with either the push or pull methods, but I wanted to
make the point that flood could benefit from both request generation
brigades/filters as well as response filtering. Flood is designed
right now so that there are phases for both receiving and verifying a
response. We'd like to be able to throw in more than one verification
module (configurable at runtime) and not have to worry about double-copy
overhead and memory constraints.
> > And, I think the API would need to be a bit more formal.
>
> Absolutely. That is why my previous email mentioned that I'd be happy to see
> a directory / cvs module get started so a roadmap could be created. I would
> want to see the API first, built from our expertise with the brigades and
> filtering systems, and with a lot of the ideas embodied in Neon's APIs.
+1
(once we get it rolling we can move this kind of discussion there and
start writing design docs)
> > And, in discussions with Roy, I think he was thinking a client
> > library should be a part of httpd not APR. But, I don't care
> > one way or another. -- justin
>
> Nah. This has utility outside of httpd. Specifically, Subversion is an
> excellent candidate. I also know that Covalent has a similar library that
> they use internally ("apua", I believe). So that is candidate #2. And then
> you have your flood program for candidate #3. Of course, mod_proxy would use
> it, but that can fall under Roy's httpd placement model.
Justin: when you say "part of httpd" do you mean "a subproject of"?
I don't really care where it goes as long as it can be used independently
of the core httpd source.
-aaron
RE: [PROPOSAL] apr-client
Posted by Sander Striker <st...@apache.org>.
> From: Greg Stein [mailto:gstein@lyra.org]
> Sent: 01 October 2001 08:27
> On Sat, Sep 29, 2001 at 01:20:52PM +0200, Sander Striker wrote:
>>> From: Ryan Bloom [mailto:rbb@covalent.net]
>>> Sent: 29 September 2001 07:19
>>...
>>> Okay, this has been decided by the PMC. We will accept this
>>> project. The name that the PMC would like to use for this
>>> project is apr-serf.
>>
>> Ok, great. One question though: why 'serf'?
>
> OtherBill had a very good point, in that "apr-client" is a bit
> too generic.
> He suggested "apr-htclient" but I thought that was a bit too much of a
> mouthful for a project name...
>
> I suggested taking a page from the XML and Java guys, and using a more
> interesting name. So... I figured "a client is subservient to the server".
> So the name "serf" works well in that regard, meaning a slave to
> the server.
> It is also a homonym for "surf", which is what an HTTP client does...
Right. Thanks for explaining, because this was indeed the only thing
I wanted to know: where it came from :)
> Seems like others agreed, and so now we have apr-serf :-)
I can live with that without problems :) :)
> Cheers,
> -g
Sander
Re: [PROPOSAL] apr-client
Posted by Greg Stein <gs...@lyra.org>.
On Sat, Sep 29, 2001 at 01:20:52PM +0200, Sander Striker wrote:
> > From: Ryan Bloom [mailto:rbb@covalent.net]
> > Sent: 29 September 2001 07:19
>...
> > Okay, this has been decided by the PMC. We will accept this project. The
> > name that the PMC would like to use for this project is apr-serf.
>
> Ok, great. One question though: why 'serf'?
OtherBill had a very good point, in that "apr-client" is a bit too generic.
He suggested "apr-htclient" but I thought that was a bit too much of a
mouthful for a project name...
I suggested taking a page from the XML and Java guys, and using a more
interesting name. So... I figured "a client is subservient to the server".
So the name "serf" works well in that regard, meaning a slave to the server.
It is also a homonym for "surf", which is what an HTTP client does...
Seems like others agreed, and so now we have apr-serf :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: [PROPOSAL] apr-client
Posted by Ryan Bloom <rb...@covalent.net>.
On Saturday 29 September 2001 08:28 am, Aaron Bannert wrote:
> On Fri, Sep 28, 2001 at 10:19:11PM -0700, Ryan Bloom wrote:
> > Okay, this has been decided by the PMC. We will accept this project.
> > The name that the PMC would like to use for this project is apr-serf. I
> > will create a repository with nothing but a STATUS file in a few minutes.
> > I will also ask Brian to setup a developers mailing list and CVS mailing
> > list.
>
> Do we really need a new developers' mailing list or can/should we
> just use dev@apr?
This project doesn't really match what the rest of APR is about, so yes,
I would like to see another mailing list. I don't know that I personally plan
to participate in this project, because it doesn't really affect the portability
library, which is what I am interested in.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: [PROPOSAL] apr-client
Posted by Ryan Bloom <rb...@covalent.net>.
On Saturday 29 September 2001 08:28 am, Aaron Bannert wrote:
> On Fri, Sep 28, 2001 at 10:19:11PM -0700, Ryan Bloom wrote:
> > Okay, this has been decided by the PMC. We will accept this project.
> > The name that the PMC would like to use for this project is apr-serf. I
> > will create a repository with nothing but a STATUS file in a few minutes.
> > I will also ask Brian to setup a developers mailing list and CVS mailing
> > list.
>
> Do we really need a new developers' mailing list or can/should we
> just use dev@apr?
This project doesn't really match what the rest of APR is about, so yes,
I would like to see another mailing list. I don't know that I personally plan
to participate in this project, because it doesn't really affect the portability
library, which is what I am interested in.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: [PROPOSAL] apr-client
Posted by Ryan Bloom <rb...@covalent.net>.
On Sunday 30 September 2001 11:30 pm, Greg Stein wrote:
Will do ASAP.
Ryan
> On Fri, Sep 28, 2001 at 10:19:11PM -0700, Ryan Bloom wrote:
> >...
> > Okay, this has been decided by the PMC. We will accept this project.
> > The name that the PMC would like to use for this project is apr-serf. I
> > will create a repository with nothing but a STATUS file in a few minutes.
> > I will also ask Brian to setup a developers mailing list and CVS mailing
> > list.
>
> Could you:
>
> $ chgrp -R apr /home/cvs/apr-serf
>
> ?? Checking it out doesn't work right now.
>
> Thx,
> -g
--
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: [PROPOSAL] apr-client
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Sep 28, 2001 at 10:19:11PM -0700, Ryan Bloom wrote:
>...
> Okay, this has been decided by the PMC. We will accept this project. The
> name that the PMC would like to use for this project is apr-serf. I will create
> a repository with nothing but a STATUS file in a few minutes. I will also ask
> Brian to setup a developers mailing list and CVS mailing list.
Could you:
$ chgrp -R apr /home/cvs/apr-serf
?? Checking it out doesn't work right now.
Thx,
-g
--
Greg Stein, http://www.lyra.org/
Re: [PROPOSAL] apr-client
Posted by Aaron Bannert <aa...@clove.org>.
On Fri, Sep 28, 2001 at 10:19:11PM -0700, Ryan Bloom wrote:
> Okay, this has been decided by the PMC. We will accept this project. The
> name that the PMC would like to use for this project is apr-serf. I will create
> a repository with nothing but a STATUS file in a few minutes. I will also ask
> Brian to setup a developers mailing list and CVS mailing list.
Do we really need a new developers' mailing list or can/should we
just use dev@apr?
-aaron
Re: [PROPOSAL] apr-client
Posted by Aaron Bannert <aa...@clove.org>.
On Fri, Sep 28, 2001 at 10:19:11PM -0700, Ryan Bloom wrote:
> Okay, this has been decided by the PMC. We will accept this project. The
> name that the PMC would like to use for this project is apr-serf. I will create
> a repository with nothing but a STATUS file in a few minutes. I will also ask
> Brian to setup a developers mailing list and CVS mailing list.
Do we really need a new developers' mailing list or can/should we
just use dev@apr?
-aaron
RE: [PROPOSAL] apr-client
Posted by Sander Striker <st...@apache.org>.
> From: Ryan Bloom [mailto:rbb@covalent.net]
> Sent: 29 September 2001 07:19
> On Wednesday 26 September 2001 05:55 pm, Ryan Bloom wrote:
> > On Wednesday 26 September 2001 05:45 pm, Roy T. Fielding wrote:
> > > > I'm still in favor of apr-client. If we want to rename the top-level
> > > > CVS directory at some point, then fine...
> > >
> > > Okay, assuming the APR PMC wants to take it on as a responsibility.
> >
> > I'll check this, and report back the results. I have counted 3
> people on
> > this list who have said that they are interested. Expect to
> have an answer
> > on this thread in 2 - 3 days.
>
> Okay, this has been decided by the PMC. We will accept this project. The
> name that the PMC would like to use for this project is apr-serf.
Ok, great. One question though: why 'serf'?
http://www.encyclopedia.com/articlesnew/11708.html
http://serfsoft.com/
http://www.webserf.com/
http://serf.org/
http://www.serf.com/
http://www.serf.ubc.ca/
http://www.netserf.org
http://www.serf.com.au/
http://www.che.udel.edu/SERF/
http://www.safesurf.com/serf.htm
There are a lot of 'serf's out there, but I'm missing the link
to an http client library. Not that I couldn't live with this name,
I'd just like to know where it came from.
> I will create
> a repository with nothing but a STATUS file in a few minutes. I
> will also ask
> Brian to setup a developers mailing list and CVS mailing list.
>
> Ryan
Ack. Thanks,
Sander
Re: [PROPOSAL] apr-client
Posted by Ryan Bloom <rb...@covalent.net>.
On Wednesday 26 September 2001 05:55 pm, Ryan Bloom wrote:
> On Wednesday 26 September 2001 05:45 pm, Roy T. Fielding wrote:
> > > I'm still in favor of apr-client. If we want to rename the top-level
> > > CVS directory at some point, then fine...
> >
> > Okay, assuming the APR PMC wants to take it on as a responsibility.
>
> I'll check this, and report back the results. I have counted 3 people on
> this list who have said that they are interested. Expect to have an answer
> on this thread in 2 - 3 days.
Okay, this has been decided by the PMC. We will accept this project. The
name that the PMC would like to use for this project is apr-serf. I will create
a repository with nothing but a STATUS file in a few minutes. I will also ask
Brian to setup a developers mailing list and CVS mailing list.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: [PROPOSAL] apr-client
Posted by Ryan Bloom <rb...@covalent.net>.
On Wednesday 26 September 2001 05:55 pm, Ryan Bloom wrote:
> On Wednesday 26 September 2001 05:45 pm, Roy T. Fielding wrote:
> > > I'm still in favor of apr-client. If we want to rename the top-level
> > > CVS directory at some point, then fine...
> >
> > Okay, assuming the APR PMC wants to take it on as a responsibility.
>
> I'll check this, and report back the results. I have counted 3 people on
> this list who have said that they are interested. Expect to have an answer
> on this thread in 2 - 3 days.
Okay, this has been decided by the PMC. We will accept this project. The
name that the PMC would like to use for this project is apr-serf. I will create
a repository with nothing but a STATUS file in a few minutes. I will also ask
Brian to setup a developers mailing list and CVS mailing list.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: [PROPOSAL] apr-client
Posted by Ryan Bloom <rb...@covalent.net>.
On Wednesday 26 September 2001 05:45 pm, Roy T. Fielding wrote:
> > I'm still in favor of apr-client. If we want to rename the top-level CVS
> > directory at some point, then fine...
>
> Okay, assuming the APR PMC wants to take it on as a responsibility.
I'll check this, and report back the results. I have counted 3 people on this
list who have said that they are interested. Expect to have an answer on this
thread in 2 - 3 days.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: [PROPOSAL] apr-client
Posted by Ryan Bloom <rb...@covalent.net>.
On Wednesday 26 September 2001 05:45 pm, Roy T. Fielding wrote:
> > I'm still in favor of apr-client. If we want to rename the top-level CVS
> > directory at some point, then fine...
>
> Okay, assuming the APR PMC wants to take it on as a responsibility.
I'll check this, and report back the results. I have counted 3 people on this
list who have said that they are interested. Expect to have an answer on this
thread in 2 - 3 days.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: [PROPOSAL] apr-client
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Sep 26, 2001 at 11:43:33PM -0500, William A. Rowe, Jr. wrote:
>...
> Think _lightweight_ guys ... if this gets unmanageable, it might need to
> become it's own project.
I think lightweight in terms of "HTTP and its extensions (HTTPS, DAV, etc)"
*only*.
Once you move into other protocols, then the whole concept falls apart.
Consider FTP: it requires *two* connections, and sometimes a *listener*.
That is just Way Too Different.
No... *just* HTTP in my book. The things a client will do: proxy, auth, ??
And using our bucket/brigade design for efficiency, and using filters for
code clarity / modularization.
> And I agree with the assertion that APR = Portability Runtime,
> APR-UTIL = Portable Runtime Utilities. We can extend that just as long
> as we remember that APR (primary) never contains anything except portability,
Agreed.
> and APR-UTIL shouldn't grow in -huge- chunks (if it exceeds 10k lines of code,
> it probably warrents it's own codebase.)
>
> Sure sounds like apr-client could fit the bill.
Agreed on both counts. Neon 0.15.3 is around 12 kloc. Removing duplication
with existing APR(UTIL) stuff, I figure that we could implement similar
functionality in about 7 kloc.
But we also have some advantages to start with: from scratch with lots of
prior work to learn from (what is good, what is bad), and lots of code to
steal from proxy, flood, and httpd.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: [PROPOSAL] apr-client
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "Roy T. Fielding" <fi...@ebuilt.com>
Sent: Wednesday, September 26, 2001 7:45 PM
> > I'm still in favor of apr-client. If we want to rename the top-level CVS
> > directory at some point, then fine...
>
> Okay, assuming the APR PMC wants to take it on as a responsibility.
+1 here, since this proves the APR Project must eat it's own dogfood :-)))
Think _lightweight_ guys ... if this gets unmanageable, it might need to
become it's own project.
And I agree with the assertion that APR = Portability Runtime,
APR-UTIL = Portable Runtime Utilities. We can extend that just as long
as we remember that APR (primary) never contains anything except portability,
and APR-UTIL shouldn't grow in -huge- chunks (if it exceeds 10k lines of code,
it probably warrents it's own codebase.)
Sure sounds like apr-client could fit the bill.
Bill
Re: [PROPOSAL] apr-client
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
> I'm still in favor of apr-client. If we want to rename the top-level CVS
> directory at some point, then fine...
Okay, assuming the APR PMC wants to take it on as a responsibility.
....Roy
Re: [PROPOSAL] apr-client
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
> I'm still in favor of apr-client. If we want to rename the top-level CVS
> directory at some point, then fine...
Okay, assuming the APR PMC wants to take it on as a responsibility.
....Roy
Re: [PROPOSAL] apr-client
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Sep 26, 2001 at 04:22:46PM -0700, Roy T. Fielding wrote:
>...
> > Nah. This has utility outside of httpd. Specifically, Subversion is an
> > excellent candidate. I also know that Covalent has a similar library that
> > they use internally ("apua", I believe). So that is candidate #2. And then
> > you have your flood program for candidate #3. Of course, mod_proxy would use
> > it, but that can fall under Roy's httpd placement model.
> >
> > And then there are the ones we don't know about...
>
> All the more reason why it shouldn't be part of the Apache Portable Runtime
> project. If you want to create a new project for it, that's fine with me,
> but the only thing it has in common with APR is that it will use APR.
Hmm. Good point, but I think it also depends a bit on how you look at APR.
As a "Runtime", it can contain any kinds of functionality. And the
"Portable" is just an adjective.
Alternatively, if you have a "runtime to create portability" ... then yah:
your point would hold.
Just playing the devil's advocate :-)
I'm still in favor of apr-client. If we want to rename the top-level CVS
directory at some point, then fine...
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: [PROPOSAL] apr-client
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Sep 26, 2001 at 04:22:46PM -0700, Roy T. Fielding wrote:
>...
> > Nah. This has utility outside of httpd. Specifically, Subversion is an
> > excellent candidate. I also know that Covalent has a similar library that
> > they use internally ("apua", I believe). So that is candidate #2. And then
> > you have your flood program for candidate #3. Of course, mod_proxy would use
> > it, but that can fall under Roy's httpd placement model.
> >
> > And then there are the ones we don't know about...
>
> All the more reason why it shouldn't be part of the Apache Portable Runtime
> project. If you want to create a new project for it, that's fine with me,
> but the only thing it has in common with APR is that it will use APR.
Hmm. Good point, but I think it also depends a bit on how you look at APR.
As a "Runtime", it can contain any kinds of functionality. And the
"Portable" is just an adjective.
Alternatively, if you have a "runtime to create portability" ... then yah:
your point would hold.
Just playing the devil's advocate :-)
I'm still in favor of apr-client. If we want to rename the top-level CVS
directory at some point, then fine...
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: [PROPOSAL] apr-client
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
> > And, in discussions with Roy, I think he was thinking a client
> > library should be a part of httpd not APR. But, I don't care
> > one way or another. -- justin
>
> Nah. This has utility outside of httpd. Specifically, Subversion is an
> excellent candidate. I also know that Covalent has a similar library that
> they use internally ("apua", I believe). So that is candidate #2. And then
> you have your flood program for candidate #3. Of course, mod_proxy would use
> it, but that can fall under Roy's httpd placement model.
>
> And then there are the ones we don't know about...
All the more reason why it shouldn't be part of the Apache Portable Runtime
project. If you want to create a new project for it, that's fine with me,
but the only thing it has in common with APR is that it will use APR.
....Roy
Re: [PROPOSAL] apr-client
Posted by Aaron Bannert <aa...@clove.org>.
On Wed, Sep 26, 2001 at 03:52:18PM -0700, Greg Stein wrote:
> > FWIW, flood in httpd-test already has 80% of what Sander suggested.
>
> Sander and I already talked about stealing code from flood and mod_proxy. :-)
*ahem* ;)
In all seriousness, I think we've already got most of the code we want.
(Flood already does or can do some of the things Sander suggested).
> > The major thing it is missing is bucket/brigade/filters - which is
> > why I'm getting pissy about the API change because I want to move
> > flood to this. (It is also missing chunking and pipelining which I
> > was working on when I got interrupted when I saw how httpd handles
> > it and started to rewrite the input filtering.)
> >
> > The one thing I would change in Sander's proposal is that I detest
> > callbacks.
>
> It should not be hard to build it such that push or pull models could be
> used here.
>
> There are four points of push/pull:
>
> 1a) app pushes request into apr-client, which then transfers it onto the
> network. this is like the output filter chain of httpd.
>
> 1b) app gives a callback to apr-client, which it uses to pull data and
> deliver it to the network. this is similar to httpd pulling data via the
> input filter chain.
>
> 2a) apr-client pushes response to an app's callback
>
> 2b) app pulls response from apr-client as it becomes available
>
>
> An application can choose 1a or 1b, and 2a or 2b for how it handles the
> request/response process. The question boils down to "who is in control?" In
> 1a and 2b, the app is in control. In 1b and 2a, the library is in control
> (based on network conditions).
>
> When Sander mentioned callbacks, he was really referring to 2a. (that aspect
> came up in our conversation; we didn't discuss 1b much).
I have no problem with either the push or pull methods, but I wanted to
make the point that flood could benefit from both request generation
brigades/filters as well as response filtering. Flood is designed
right now so that there are phases for both receiving and verifying a
response. We'd like to be able to throw in more than one verification
module (configurable at runtime) and not have to worry about double-copy
overhead and memory constraints.
> > And, I think the API would need to be a bit more formal.
>
> Absolutely. That is why my previous email mentioned that I'd be happy to see
> a directory / cvs module get started so a roadmap could be created. I would
> want to see the API first, built from our expertise with the brigades and
> filtering systems, and with a lot of the ideas embodied in Neon's APIs.
+1
(once we get it rolling we can move this kind of discussion there and
start writing design docs)
> > And, in discussions with Roy, I think he was thinking a client
> > library should be a part of httpd not APR. But, I don't care
> > one way or another. -- justin
>
> Nah. This has utility outside of httpd. Specifically, Subversion is an
> excellent candidate. I also know that Covalent has a similar library that
> they use internally ("apua", I believe). So that is candidate #2. And then
> you have your flood program for candidate #3. Of course, mod_proxy would use
> it, but that can fall under Roy's httpd placement model.
Justin: when you say "part of httpd" do you mean "a subproject of"?
I don't really care where it goes as long as it can be used independently
of the core httpd source.
-aaron
Re: [PROPOSAL] apr-client
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
> > And, in discussions with Roy, I think he was thinking a client
> > library should be a part of httpd not APR. But, I don't care
> > one way or another. -- justin
>
> Nah. This has utility outside of httpd. Specifically, Subversion is an
> excellent candidate. I also know that Covalent has a similar library that
> they use internally ("apua", I believe). So that is candidate #2. And then
> you have your flood program for candidate #3. Of course, mod_proxy would use
> it, but that can fall under Roy's httpd placement model.
>
> And then there are the ones we don't know about...
All the more reason why it shouldn't be part of the Apache Portable Runtime
project. If you want to create a new project for it, that's fine with me,
but the only thing it has in common with APR is that it will use APR.
....Roy
Re: [PROPOSAL] apr-client
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Sep 26, 2001 at 03:33:12PM -0700, Justin Erenkrantz wrote:
> On Wed, Sep 26, 2001 at 03:21:42PM -0700, Greg Stein wrote:
> > But that said, I'm am a BIG +1 on adding an http client library into the
> > ASF's APR project. Whether people want that to go into apr-util or into a
> > new apr-client, I'm not too concerned.
>
> FWIW, flood in httpd-test already has 80% of what Sander suggested.
Sander and I already talked about stealing code from flood and mod_proxy. :-)
> The major thing it is missing is bucket/brigade/filters - which is
> why I'm getting pissy about the API change because I want to move
> flood to this. (It is also missing chunking and pipelining which I
> was working on when I got interrupted when I saw how httpd handles
> it and started to rewrite the input filtering.)
>
> The one thing I would change in Sander's proposal is that I detest
> callbacks.
It should not be hard to build it such that push or pull models could be
used here.
There are four points of push/pull:
1a) app pushes request into apr-client, which then transfers it onto the
network. this is like the output filter chain of httpd.
1b) app gives a callback to apr-client, which it uses to pull data and
deliver it to the network. this is similar to httpd pulling data via the
input filter chain.
2a) apr-client pushes response to an app's callback
2b) app pulls response from apr-client as it becomes available
An application can choose 1a or 1b, and 2a or 2b for how it handles the
request/response process. The question boils down to "who is in control?" In
1a and 2b, the app is in control. In 1b and 2a, the library is in control
(based on network conditions).
When Sander mentioned callbacks, he was really referring to 2a. (that aspect
came up in our conversation; we didn't discuss 1b much).
> And, I think the API would need to be a bit more formal.
Absolutely. That is why my previous email mentioned that I'd be happy to see
a directory / cvs module get started so a roadmap could be created. I would
want to see the API first, built from our expertise with the brigades and
filtering systems, and with a lot of the ideas embodied in Neon's APIs.
> And, the build process cleaned up. And, more testing.
> Yadda, yadda, yadda.
Of course :-)
> And, in discussions with Roy, I think he was thinking a client
> library should be a part of httpd not APR. But, I don't care
> one way or another. -- justin
Nah. This has utility outside of httpd. Specifically, Subversion is an
excellent candidate. I also know that Covalent has a similar library that
they use internally ("apua", I believe). So that is candidate #2. And then
you have your flood program for candidate #3. Of course, mod_proxy would use
it, but that can fall under Roy's httpd placement model.
And then there are the ones we don't know about...
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: [PROPOSAL] apr-client
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Sep 26, 2001 at 03:33:12PM -0700, Justin Erenkrantz wrote:
> On Wed, Sep 26, 2001 at 03:21:42PM -0700, Greg Stein wrote:
> > But that said, I'm am a BIG +1 on adding an http client library into the
> > ASF's APR project. Whether people want that to go into apr-util or into a
> > new apr-client, I'm not too concerned.
>
> FWIW, flood in httpd-test already has 80% of what Sander suggested.
Sander and I already talked about stealing code from flood and mod_proxy. :-)
> The major thing it is missing is bucket/brigade/filters - which is
> why I'm getting pissy about the API change because I want to move
> flood to this. (It is also missing chunking and pipelining which I
> was working on when I got interrupted when I saw how httpd handles
> it and started to rewrite the input filtering.)
>
> The one thing I would change in Sander's proposal is that I detest
> callbacks.
It should not be hard to build it such that push or pull models could be
used here.
There are four points of push/pull:
1a) app pushes request into apr-client, which then transfers it onto the
network. this is like the output filter chain of httpd.
1b) app gives a callback to apr-client, which it uses to pull data and
deliver it to the network. this is similar to httpd pulling data via the
input filter chain.
2a) apr-client pushes response to an app's callback
2b) app pulls response from apr-client as it becomes available
An application can choose 1a or 1b, and 2a or 2b for how it handles the
request/response process. The question boils down to "who is in control?" In
1a and 2b, the app is in control. In 1b and 2a, the library is in control
(based on network conditions).
When Sander mentioned callbacks, he was really referring to 2a. (that aspect
came up in our conversation; we didn't discuss 1b much).
> And, I think the API would need to be a bit more formal.
Absolutely. That is why my previous email mentioned that I'd be happy to see
a directory / cvs module get started so a roadmap could be created. I would
want to see the API first, built from our expertise with the brigades and
filtering systems, and with a lot of the ideas embodied in Neon's APIs.
> And, the build process cleaned up. And, more testing.
> Yadda, yadda, yadda.
Of course :-)
> And, in discussions with Roy, I think he was thinking a client
> library should be a part of httpd not APR. But, I don't care
> one way or another. -- justin
Nah. This has utility outside of httpd. Specifically, Subversion is an
excellent candidate. I also know that Covalent has a similar library that
they use internally ("apua", I believe). So that is candidate #2. And then
you have your flood program for candidate #3. Of course, mod_proxy would use
it, but that can fall under Roy's httpd placement model.
And then there are the ones we don't know about...
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: [PROPOSAL] apr-client
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Wed, Sep 26, 2001 at 03:21:42PM -0700, Greg Stein wrote:
> But that said, I'm am a BIG +1 on adding an http client library into the
> ASF's APR project. Whether people want that to go into apr-util or into a
> new apr-client, I'm not too concerned.
FWIW, flood in httpd-test already has 80% of what Sander suggested.
The major thing it is missing is bucket/brigade/filters - which is
why I'm getting pissy about the API change because I want to move
flood to this. (It is also missing chunking and pipelining which I
was working on when I got interrupted when I saw how httpd handles
it and started to rewrite the input filtering.)
The one thing I would change in Sander's proposal is that I detest
callbacks. And, I think the API would need to be a bit more
formal. And, the build process cleaned up. And, more testing.
Yadda, yadda, yadda.
And, in discussions with Roy, I think he was thinking a client
library should be a part of httpd not APR. But, I don't care
one way or another. -- justin
Re: [PROPOSAL] apr-client
Posted by Ryan Bloom <rb...@covalent.net>.
On Wednesday 26 September 2001 03:21 pm, Greg Stein wrote:
> Umm... Ryan... *what* are you talking about? :-)
Ooops, you're right. I misremembered the uri parsing stuff. My fault.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: [PROPOSAL] apr-client
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Wed, Sep 26, 2001 at 03:21:42PM -0700, Greg Stein wrote:
> But that said, I'm am a BIG +1 on adding an http client library into the
> ASF's APR project. Whether people want that to go into apr-util or into a
> new apr-client, I'm not too concerned.
FWIW, flood in httpd-test already has 80% of what Sander suggested.
The major thing it is missing is bucket/brigade/filters - which is
why I'm getting pissy about the API change because I want to move
flood to this. (It is also missing chunking and pipelining which I
was working on when I got interrupted when I saw how httpd handles
it and started to rewrite the input filtering.)
The one thing I would change in Sander's proposal is that I detest
callbacks. And, I think the API would need to be a bit more
formal. And, the build process cleaned up. And, more testing.
Yadda, yadda, yadda.
And, in discussions with Roy, I think he was thinking a client
library should be a part of httpd not APR. But, I don't care
one way or another. -- justin
Re: [PROPOSAL] apr-client
Posted by Ryan Bloom <rb...@covalent.net>.
On Wednesday 26 September 2001 03:21 pm, Greg Stein wrote:
> Umm... Ryan... *what* are you talking about? :-)
Ooops, you're right. I misremembered the uri parsing stuff. My fault.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: [PROPOSAL] apr-client
Posted by Greg Stein <gs...@lyra.org>.
Umm... Ryan... *what* are you talking about? :-)
I do not recall ever discussing a client library in there. Nor as a
motivation for APRUTIL. I'm happy to be disproved on that :-), but I'd
rather see a separate library started for this. An http client library is a
big chunk of code.
I just counted the LOC in aprutil just now. 24 kLOC. I would estimate that
apr-client to be in the neighborhood of 7k to 10k LOC. That is a *big*
change over today's apr-util.
But that said, I'm am a BIG +1 on adding an http client library into the
ASF's APR project. Whether people want that to go into apr-util or into a
new apr-client, I'm not too concerned.
Let's say:
+1 on creating apr-client
-0 on adding to apr-util [ but +1 if apr-client rejected :-) ]
Cheers,
-g
On Wed, Sep 26, 2001 at 02:46:44PM -0700, Ryan Bloom wrote:
>
> There is supposed to be an http client library as a part of apr-util.
> It's just that nobody has actually written it yet. I would prefer to not
> create another library for this, because this client lib was one of the
> reasons that apr-util was created in the first place.
>
> Ryan
>
> On Wednesday 26 September 2001 02:14 pm, Sander Striker wrote:
> > Hi all,
> >
> > I wish to propose a new library: apr-client.
>...
--
Greg Stein, http://www.lyra.org/
Re: [PROPOSAL] apr-client
Posted by Greg Stein <gs...@lyra.org>.
Umm... Ryan... *what* are you talking about? :-)
I do not recall ever discussing a client library in there. Nor as a
motivation for APRUTIL. I'm happy to be disproved on that :-), but I'd
rather see a separate library started for this. An http client library is a
big chunk of code.
I just counted the LOC in aprutil just now. 24 kLOC. I would estimate that
apr-client to be in the neighborhood of 7k to 10k LOC. That is a *big*
change over today's apr-util.
But that said, I'm am a BIG +1 on adding an http client library into the
ASF's APR project. Whether people want that to go into apr-util or into a
new apr-client, I'm not too concerned.
Let's say:
+1 on creating apr-client
-0 on adding to apr-util [ but +1 if apr-client rejected :-) ]
Cheers,
-g
On Wed, Sep 26, 2001 at 02:46:44PM -0700, Ryan Bloom wrote:
>
> There is supposed to be an http client library as a part of apr-util.
> It's just that nobody has actually written it yet. I would prefer to not
> create another library for this, because this client lib was one of the
> reasons that apr-util was created in the first place.
>
> Ryan
>
> On Wednesday 26 September 2001 02:14 pm, Sander Striker wrote:
> > Hi all,
> >
> > I wish to propose a new library: apr-client.
>...
--
Greg Stein, http://www.lyra.org/
Re: [PROPOSAL] apr-client
Posted by Ryan Bloom <rb...@covalent.net>.
On Wednesday 26 September 2001 02:14 pm, Sander Striker wrote:
There is supposed to be an http client library as a part of apr-util.
It's just that nobody has actually written it yet. I would prefer to not
create another library for this, because this client lib was one of the
reasons that apr-util was created in the first place.
Ryan
> Hi all,
>
> I wish to propose a new library: apr-client.
> It is basically a http client library. I see
> a direct use for at least three projects:
> - mod_proxy (which has most of the code in it),
> - flood (to do more flexible testing, for example
> with authentication, or even ssl client auth),
> - subversion (which is currently using neon).
>
> The library is going to be based on apr
> and apr-util, and will have an optional dependency
> on openssl (through a --with-ssl[=path] switch).
>
> Features:
> - sessions
> - request building
> - response parsing
> - pipelining
> - authentication support
> - filters
> - like ssl, gz, chunk
>
> Callbacks will be used to drive events (like responses,
> or the need for auth information).
>
> The library should make heavy use of buckets/brigades,
> I dare even say the request building is a thin wrapper
> around those.
>
> Requests supported should be all HTTP requests and
> the DAV extensions.
>
> The filters are a nice area for code reuse. The logic
> for the client is ofcourse reversed, so we can have
> a chunk filter on the request side and a dechunk on the
> response side. This is just an example, replace
> chunk/dechunk with gzip/unzip and you have another.
> Same goes for ssl. This way the same code gets used in
> multiple places which results in more extensive testing
> of this code (which is a nice side effect).
>
> You might ask yourself why the world would need yet
> another http client library. Well, there seem to be
> only two good ones: curl and neon. Curl is bloated
> (has ftp, gopher, etc support and is more a general
> network client library). Neon is good, but LGPL. Also,
> it doesn't tie in nicely with apr (example is malloc/free
> usage in it, which requires the user to malloc a chunk
> of mem, fill it, pass it to neon which then frees it).
>
> Well, this mail isn't the extensive description I wanted
> to give*, but surely enough to get some feedback.
>
> Sander
>
> *) Am a bit distracted for some reason.
--
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: [PROPOSAL] apr-client
Posted by Ryan Bloom <rb...@covalent.net>.
On Wednesday 26 September 2001 02:14 pm, Sander Striker wrote:
There is supposed to be an http client library as a part of apr-util.
It's just that nobody has actually written it yet. I would prefer to not
create another library for this, because this client lib was one of the
reasons that apr-util was created in the first place.
Ryan
> Hi all,
>
> I wish to propose a new library: apr-client.
> It is basically a http client library. I see
> a direct use for at least three projects:
> - mod_proxy (which has most of the code in it),
> - flood (to do more flexible testing, for example
> with authentication, or even ssl client auth),
> - subversion (which is currently using neon).
>
> The library is going to be based on apr
> and apr-util, and will have an optional dependency
> on openssl (through a --with-ssl[=path] switch).
>
> Features:
> - sessions
> - request building
> - response parsing
> - pipelining
> - authentication support
> - filters
> - like ssl, gz, chunk
>
> Callbacks will be used to drive events (like responses,
> or the need for auth information).
>
> The library should make heavy use of buckets/brigades,
> I dare even say the request building is a thin wrapper
> around those.
>
> Requests supported should be all HTTP requests and
> the DAV extensions.
>
> The filters are a nice area for code reuse. The logic
> for the client is ofcourse reversed, so we can have
> a chunk filter on the request side and a dechunk on the
> response side. This is just an example, replace
> chunk/dechunk with gzip/unzip and you have another.
> Same goes for ssl. This way the same code gets used in
> multiple places which results in more extensive testing
> of this code (which is a nice side effect).
>
> You might ask yourself why the world would need yet
> another http client library. Well, there seem to be
> only two good ones: curl and neon. Curl is bloated
> (has ftp, gopher, etc support and is more a general
> network client library). Neon is good, but LGPL. Also,
> it doesn't tie in nicely with apr (example is malloc/free
> usage in it, which requires the user to malloc a chunk
> of mem, fill it, pass it to neon which then frees it).
>
> Well, this mail isn't the extensive description I wanted
> to give*, but surely enough to get some feedback.
>
> Sander
>
> *) Am a bit distracted for some reason.
--
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------