You are viewing a plain text version of this content. The canonical link for it is here.
Posted to serf-dev@apr.apache.org by Justin Erenkrantz <je...@apache.org> on 2002/11/04 09:42:24 UTC
Moving serf to commons?
Does anyone want to spearhead moving apr-serf to commons?
While I want to move it, I don't have the necessary karma/knowhow to
do that, and I'd rather spend what little time I do have to spend on
serf writing more code. (Next on my list is deflate support.)
So, do we have any volunteers? =) -- justin
Re: Moving serf to commons?
Posted by Justin Erenkrantz <je...@apache.org>.
--On Monday, November 04, 2002 11:17:26 -0800 Greg Stein <gs...@lyra.org>
wrote:
> Hmm. Maybe we should use Subversion? We could certainly not worry about
> directory organization in that case. We'd lose CVS history, though, since
> we can't blend multiple CVS repositories over time. i.e. we could use
> cvs2svn for an initial set, but future additions would lose history since
> we couldn't "blend" them into an existing repos.
I would personally be a strong +1 for using Subversion for serf. I think
Subversion is ready for a trial run here within the ASF.
That said, I'm going to stay the heck out of this policy debate. I want to
see serf move to commons, but I'm not going to waste my breath arguing over
it. I've stated my position, and I'd rather spend my time improving the
code. -- justin
Re: Moving serf to commons?
Posted by Justin Erenkrantz <je...@apache.org>.
--On Monday, November 04, 2002 11:17:26 -0800 Greg Stein <gs...@lyra.org>
wrote:
> Hmm. Maybe we should use Subversion? We could certainly not worry about
> directory organization in that case. We'd lose CVS history, though, since
> we can't blend multiple CVS repositories over time. i.e. we could use
> cvs2svn for an initial set, but future additions would lose history since
> we couldn't "blend" them into an existing repos.
I would personally be a strong +1 for using Subversion for serf. I think
Subversion is ready for a trial run here within the ASF.
That said, I'm going to stay the heck out of this policy debate. I want to
see serf move to commons, but I'm not going to waste my breath arguing over
it. I've stated my position, and I'd rather spend my time improving the
code. -- justin
Re: Moving serf to commons?
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Nov 04, 2002 at 11:43:43AM -0800, Aaron Bannert wrote:
> On Mon, Nov 04, 2002 at 11:17:26AM -0800, Greg Stein wrote:
> > I can definitely do it, but Aaron's being a butthead with a -1 saying it
> > doesn't fit the Commons' goals :-)
>
> Naw, that's not true, I'm not saying it doesn't fit the goals. I'm
> saying we don't have goals to fit.
Yah, I know. But you're saying serf can't / shouldn't move because of a lack
of goals. So what is missing from Commons' goals? We've got a number of
items decided, and it seems that serf fits into those items.
IOW, what is the delta from here to >there< such that you feel Commons has a
well (enough) defined goals/mission?
> > Aaron: if you say "no", then what still
> > needs to happen to define those goals?
>
> That's easy:
>
> 1) APR needs to finalize its mission
Screw the APR mission. As Ryan pointed out, the serf project has decided
independently that it wants to move. Feel free to discuss the APR mission
with serf as a measuring stick, but the APR mission no longer has any
bearing on serf's move.
> 2) Commmons needs to finalize its mission (or have something final enough
> to start accepting things like Serf)
Take a look at the current STATUS doc. Vote where you haven't, and if the
mission isn't finalized enough, then please clarify. I don't know what
actions to take to move towards clarity.
> > Help out here, so we can get
> > component adoption going.
>
> I'd like to see Commons create an "HTTP Utilities Component" and figure
> out what that can mean.
This is your idea, so go ahead and push it :-)
I'd say "go ahead and shift serf" and when you have your concept defined,
then we wrap it around serf. IOW, does the definition need to impede the
operational aspects of moving the serf codebase?
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Moving serf to commons?
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Nov 04, 2002 at 11:43:43AM -0800, Aaron Bannert wrote:
> On Mon, Nov 04, 2002 at 11:17:26AM -0800, Greg Stein wrote:
> > I can definitely do it, but Aaron's being a butthead with a -1 saying it
> > doesn't fit the Commons' goals :-)
>
> Naw, that's not true, I'm not saying it doesn't fit the goals. I'm
> saying we don't have goals to fit.
Yah, I know. But you're saying serf can't / shouldn't move because of a lack
of goals. So what is missing from Commons' goals? We've got a number of
items decided, and it seems that serf fits into those items.
IOW, what is the delta from here to >there< such that you feel Commons has a
well (enough) defined goals/mission?
> > Aaron: if you say "no", then what still
> > needs to happen to define those goals?
>
> That's easy:
>
> 1) APR needs to finalize its mission
Screw the APR mission. As Ryan pointed out, the serf project has decided
independently that it wants to move. Feel free to discuss the APR mission
with serf as a measuring stick, but the APR mission no longer has any
bearing on serf's move.
> 2) Commmons needs to finalize its mission (or have something final enough
> to start accepting things like Serf)
Take a look at the current STATUS doc. Vote where you haven't, and if the
mission isn't finalized enough, then please clarify. I don't know what
actions to take to move towards clarity.
> > Help out here, so we can get
> > component adoption going.
>
> I'd like to see Commons create an "HTTP Utilities Component" and figure
> out what that can mean.
This is your idea, so go ahead and push it :-)
I'd say "go ahead and shift serf" and when you have your concept defined,
then we wrap it around serf. IOW, does the definition need to impede the
operational aspects of moving the serf codebase?
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Moving serf to commons?
Posted by Aaron Bannert <aa...@clove.org>.
On Mon, Nov 04, 2002 at 11:17:26AM -0800, Greg Stein wrote:
> I can definitely do it, but Aaron's being a butthead with a -1 saying it
> doesn't fit the Commons' goals :-)
Naw, that's not true, I'm not saying it doesn't fit the goals. I'm
saying we don't have goals to fit.
> Aaron: if you say "no", then what still
> needs to happen to define those goals?
That's easy:
1) APR needs to finalize its mission
2) Commmons needs to finalize its mission (or have something final enough
to start accepting things like Serf)
> Help out here, so we can get
> component adoption going.
I'd like to see Commons create an "HTTP Utilities Component" and figure
out what that can mean.
> I believe Peter wants to start shifting a bunch of
> Avalon components, too. There may be some J-C guys, too.
>
> But about serf specifically, I haven't seen votes on it from Ken, Jim, or
> Geir. We also don't seem to have a solid consensus on CVS organization or
> mailing lists.
>
> Hmm. Maybe we should use Subversion? We could certainly not worry about
> directory organization in that case. We'd lose CVS history, though, since we
> can't blend multiple CVS repositories over time. i.e. we could use cvs2svn
> for an initial set, but future additions would lose history since we
> couldn't "blend" them into an existing repos.
>
>
> [grrr...]
>
> I think it is time to stop dicking around, complete the Commons' mission
> statement, and start getting some work done.
+1
-aaron
Re: Moving serf to commons?
Posted by Aaron Bannert <aa...@clove.org>.
On Mon, Nov 04, 2002 at 11:17:26AM -0800, Greg Stein wrote:
> I can definitely do it, but Aaron's being a butthead with a -1 saying it
> doesn't fit the Commons' goals :-)
Naw, that's not true, I'm not saying it doesn't fit the goals. I'm
saying we don't have goals to fit.
> Aaron: if you say "no", then what still
> needs to happen to define those goals?
That's easy:
1) APR needs to finalize its mission
2) Commmons needs to finalize its mission (or have something final enough
to start accepting things like Serf)
> Help out here, so we can get
> component adoption going.
I'd like to see Commons create an "HTTP Utilities Component" and figure
out what that can mean.
> I believe Peter wants to start shifting a bunch of
> Avalon components, too. There may be some J-C guys, too.
>
> But about serf specifically, I haven't seen votes on it from Ken, Jim, or
> Geir. We also don't seem to have a solid consensus on CVS organization or
> mailing lists.
>
> Hmm. Maybe we should use Subversion? We could certainly not worry about
> directory organization in that case. We'd lose CVS history, though, since we
> can't blend multiple CVS repositories over time. i.e. we could use cvs2svn
> for an initial set, but future additions would lose history since we
> couldn't "blend" them into an existing repos.
>
>
> [grrr...]
>
> I think it is time to stop dicking around, complete the Commons' mission
> statement, and start getting some work done.
+1
-aaron
Re: Moving serf to commons?
Posted by Peter Donald <pe...@apache.org>.
On Tue, 5 Nov 2002 07:59, Greg Stein wrote:
> Oh... just thought of one thing. While the commit date gets shifted to a
> non-standard date property, the converted tags would be correct. If
> somebody was interested in "avalon component FOO, v0.6", then they could go
> to (say) /tags/avalon-FOO/0.6 and see the component as it was at that tag.
> It is only by-date querying that we lose.
>
> [ but we could easily build a tool to do the query on the alternate date
> property. for example:
>
> $ get-rev avalon-commit-date 'Nov 2, 2000'
> 4772
> $
That works for me. Mostly we just want the tags and dates are sugar. I will
ask on Avalon if anyone objects when the time comes.
--
Cheers,
Peter Donald
"Artists can color the sky red because they know it's blue. Those of us who
aren't artists must color things the way they really are or people might
think we're stupid." -- Jules Feiffer
Re: Moving serf to commons?
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Nov 05, 2002 at 07:42:12AM +1100, Peter Donald wrote:
> On Tue, 5 Nov 2002 06:17, Greg Stein wrote:
>...
> > We could certainly not worry about
> > directory organization in that case. We'd lose CVS history, though, since
> > we can't blend multiple CVS repositories over time. i.e. we could use
> > cvs2svn for an initial set, but future additions would lose history since
> > we couldn't "blend" them into an existing repos.
>
> that would suck! Hmmm .. no way at all to do this? Even hand hacking the db or
> something?
Oh, cvs2svn can convert any number of repositories, and jam them all into a
single SVN repository. Later on, you could convert some more and add them to
the repository. The problem that arises is that the revisions are no longer
time-ordered. (the additional set could have commits from before the first
set) It turns the question of "give me the revision for <this> date" into a
linear search problem :-(
If we had the components up front, then we'd do one big-ass conversion of
the CVS repositories, and all the revisions for the components' commits
would be interleaved. It is when you migrate components later on...
Of course, you *could* add components later if you're all right with
revision numbers changing on the resulting repository (through revamping the
existing repos to interleave the new component). But that would suck hard.
In practice, we use revision numbers like tags or reference points in
discussion. e.g. "fixed in rev 2632" or "svn 0.14.3 is /trunk at rev 3200"
If the revision number changes for some logical/semantic revision, then all
those references are horked.
Hmm. It could be possible to add components later on if we didn't worry
about their original commit date. We could retain the history, but lose the
dates. (well, we could record the dates in a non-standard date property for
reference, but something like 'svn co -r {nov 2, 2000} ...' would not work)
Oh... just thought of one thing. While the commit date gets shifted to a
non-standard date property, the converted tags would be correct. If somebody
was interested in "avalon component FOO, v0.6", then they could go to (say)
/tags/avalon-FOO/0.6 and see the component as it was at that tag. It is only
by-date querying that we lose.
[ but we could easily build a tool to do the query on the alternate date
property. for example:
$ get-rev avalon-commit-date 'Nov 2, 2000'
4772
$
(where 4772 has a standard date of the time of the repos conversion)
]
For serf, we don't care about history. For more-developed components,
especially those with releases, it could be very useful to retain the
history.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Moving serf to commons?
Posted by Peter Donald <pe...@apache.org>.
On Tue, 5 Nov 2002 06:17, Greg Stein wrote:
> I can definitely do it, but Aaron's being a butthead with a -1 saying it
> doesn't fit the Commons' goals :-) Aaron: if you say "no", then what still
> needs to happen to define those goals? Help out here, so we can get
> component adoption going. I believe Peter wants to start shifting a bunch
> of Avalon components, too.
Yep. Expect a proposal of about 15 components once the gates open ;)
> Hmm. Maybe we should use Subversion?
That would be great!
> We could certainly not worry about
> directory organization in that case. We'd lose CVS history, though, since
> we can't blend multiple CVS repositories over time. i.e. we could use
> cvs2svn for an initial set, but future additions would lose history since
> we couldn't "blend" them into an existing repos.
that would suck! Hmmm .. no way at all to do this? Even hand hacking the db or
something?
> I think it is time to stop dicking around, complete the Commons' mission
> statement, and start getting some work done.
+1
--
Cheers,
Peter Donald
-----------------------------------------------
"You can't depend on your eyes when your
imagination is out of focus." -Mark Twain
-----------------------------------------------
Re: Moving serf to commons?
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Nov 04, 2002 at 12:42:24AM -0800, Justin Erenkrantz wrote:
> Does anyone want to spearhead moving apr-serf to commons?
>
> While I want to move it, I don't have the necessary karma/knowhow to
> do that, and I'd rather spend what little time I do have to spend on
> serf writing more code. (Next on my list is deflate support.)
>
> So, do we have any volunteers? =) -- justin
I can definitely do it, but Aaron's being a butthead with a -1 saying it
doesn't fit the Commons' goals :-) Aaron: if you say "no", then what still
needs to happen to define those goals? Help out here, so we can get
component adoption going. I believe Peter wants to start shifting a bunch of
Avalon components, too. There may be some J-C guys, too.
But about serf specifically, I haven't seen votes on it from Ken, Jim, or
Geir. We also don't seem to have a solid consensus on CVS organization or
mailing lists.
Hmm. Maybe we should use Subversion? We could certainly not worry about
directory organization in that case. We'd lose CVS history, though, since we
can't blend multiple CVS repositories over time. i.e. we could use cvs2svn
for an initial set, but future additions would lose history since we
couldn't "blend" them into an existing repos.
[grrr...]
I think it is time to stop dicking around, complete the Commons' mission
statement, and start getting some work done.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Moving serf to commons?
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Nov 04, 2002 at 11:34:19AM -0800, Aaron Bannert wrote:
>...
> I totally agree with almost all of the points you have made above. I'm
> simply asking for us to draw the lines and make the boundaries BEFORE we
> go kicking code and projects around. Fine, go ahead and remove SERF from
> APR, but don't be surprised if APR is suddenly subsumed into Commons.
hehe...
/me pulls out his Automated Resolution Construction Kit and starts feeding
it some parameters...
;-)
[ and yes, the current direction for Commons' mission *does* leave room for
APR; but code doesn't *have* to live in Commons just because Commons'
goals happens to incorporate that code; I fully expect that we'll end up
spinning popular components out of Commons over time; consider APR as a
"pre-spun" component :-) ]
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Moving serf to commons?
Posted by Aaron Bannert <aa...@clove.org>.
On Mon, Nov 04, 2002 at 02:22:28PM -0500, Ryan Bloom wrote:
> > Woah woah woah...let's not be too hasty here. Just another week or so
> > and we'll have the APR mission settled and have a solid target where
> > this will go in Commons (or not). I'd be much happier to move things
> > around after we know what we're moving out of and where we're moving to,
> > since otherwise we're just strong arming this out of APR (which is an
> > act I'm strongly opposed to). Patience. :).
>
> I'm sorry, I don't understand this. Why exactly are you so hell bent on
> keeping this in APR? The vote was taken in apr-serf, and the PMC was
> asked if this should be moved. The answer was yes. Move it already. If
> apr-util moves out of APR too, then so be it, but apr-serf has already
> made the decision to move.
It has been obvious from the beginning that you were not interested
in having Serf in APR, and that's fine. I would be fine with moving it
too once we know
1) why we are moving it
2) from where it is coming (why it doesn't fit in APR)
3) to where it is going (why it fits in Commons)
None of those have been answered, let alone come to a consensus on.
> When APR was created it was supposed to be about creating a project that
> allows people to write portable C code. At the beginning, we moved a lot
> of code from httpd to APR that probably shouldn't have been moved. That
> was a mistake. We tried to correct the mistake by creating APR-util
> (which some of us fought against, because the project isn't about
> portability). That too was a mistake. The code should have been moved
> out of APR and put back in httpd-2.0.
+1
> Then, we created apr-iconv. A project whose goal is to allow portable
> codepage conversion. That project should stay, because it is about
> portability.
+1
> Finally, we created apr-serf. A project that has nothing to do with
> portability, except that it uses a portable run-time, and it is a
> library. In no way what-so-ever, can it be called a portability project.
The point of Serf is not just to create an HTTP Client library. It must
also be portable. I agree that this doesn't align perfectly with the goals
of APR, but it is false to say it is not about portability when it
is one of the main overriding goals.
> As for apr-util, since it's creation, we have added some code that acts
> as glue code for disparate back-ends. That can be considered portability
> code, so maybe it should stay. I don't know. What I do know, is that
> apr-util is not a useful library. Not because it doesn't have useful
> code, but because there is nothing tying the code together.
+1
> Try asking yourself the question:
>
> When would you recommend that somebody look into using ____?
>
> APR:
> If they need to write portable C code.
>
> APR-iconv:
> If they need to write portable C code in that deals with multiple
> charsets.
>
> APR-util:
> I haven't got a clue. If they need one interface to a lot of
> DBs? One interface to an XML parser? One interface to data stores? If
> you have a modular program and want some cool macros? What is the
> underlying goal of this code base? If it is to create some cool routines
> for Apache, then put it in Apache. If it is to be glue code for disparate
> backends, then remove everything that doesn't fit that goal, and keep in
> APR.
>
> APR-serf:
> If they need access to a portable HTTP client library.
>
> Notice that APR-util and APR-serf don't help you write portable
> code. They are inherntly portable. That isn't APR's goal, and it never
> was. If you want it to be the APR project's goal, then make that the
> goal, but that isn't the way the vote is leaning. However, that is the
> goal for commons, so the packages belong there.
I totally agree with almost all of the points you have made above. I'm
simply asking for us to draw the lines and make the boundaries BEFORE we
go kicking code and projects around. Fine, go ahead and remove SERF from
APR, but don't be surprised if APR is suddenly subsumed into Commons.
-aaron
Re: Moving serf to commons?
Posted by rb...@apache.org.
On Mon, 4 Nov 2002, Aaron Bannert wrote:
> On Mon, Nov 04, 2002 at 12:42:24AM -0800, Justin Erenkrantz wrote:
> > Does anyone want to spearhead moving apr-serf to commons?
> >
> > While I want to move it, I don't have the necessary karma/knowhow to
> > do that, and I'd rather spend what little time I do have to spend on
> > serf writing more code. (Next on my list is deflate support.)
> >
> > So, do we have any volunteers? =) -- justin
>
> Woah woah woah...let's not be too hasty here. Just another week or so
> and we'll have the APR mission settled and have a solid target where
> this will go in Commons (or not). I'd be much happier to move things
> around after we know what we're moving out of and where we're moving to,
> since otherwise we're just strong arming this out of APR (which is an
> act I'm strongly opposed to). Patience. :).
I'm sorry, I don't understand this. Why exactly are you so hell bent on
keeping this in APR? The vote was taken in apr-serf, and the PMC was
asked if this should be moved. The answer was yes. Move it already. If
apr-util moves out of APR too, then so be it, but apr-serf has already
made the decision to move.
When APR was created it was supposed to be about creating a project that
allows people to write portable C code. At the beginning, we moved a lot
of code from httpd to APR that probably shouldn't have been moved. That
was a mistake. We tried to correct the mistake by creating APR-util
(which some of us fought against, because the project isn't about
portability). That too was a mistake. The code should have been moved
out of APR and put back in httpd-2.0.
Then, we created apr-iconv. A project whose goal is to allow portable
codepage conversion. That project should stay, because it is about
portability.
Finally, we created apr-serf. A project that has nothing to do with
portability, except that it uses a portable run-time, and it is a
library. In no way what-so-ever, can it be called a portability project.
As for apr-util, since it's creation, we have added some code that acts
as glue code for disparate back-ends. That can be considered portability
code, so maybe it should stay. I don't know. What I do know, is that
apr-util is not a useful library. Not because it doesn't have useful
code, but because there is nothing tying the code together.
Try asking yourself the question:
When would you recommend that somebody look into using ____?
APR:
If they need to write portable C code.
APR-iconv:
If they need to write portable C code in that deals with multiple
charsets.
APR-util:
I haven't got a clue. If they need one interface to a lot of
DBs? One interface to an XML parser? One interface to data stores? If
you have a modular program and want some cool macros? What is the
underlying goal of this code base? If it is to create some cool routines
for Apache, then put it in Apache. If it is to be glue code for disparate
backends, then remove everything that doesn't fit that goal, and keep in
APR.
APR-serf:
If they need access to a portable HTTP client library.
Notice that APR-util and APR-serf don't help you write portable
code. They are inherntly portable. That isn't APR's goal, and it never
was. If you want it to be the APR project's goal, then make that the
goal, but that isn't the way the vote is leaning. However, that is the
goal for commons, so the packages belong there.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
550 Jean St
Oakland CA 94610
-------------------------------------------------------------------------------
Re: Moving serf to commons?
Posted by Aaron Bannert <aa...@clove.org>.
On Mon, Nov 04, 2002 at 12:42:24AM -0800, Justin Erenkrantz wrote:
> Does anyone want to spearhead moving apr-serf to commons?
>
> While I want to move it, I don't have the necessary karma/knowhow to
> do that, and I'd rather spend what little time I do have to spend on
> serf writing more code. (Next on my list is deflate support.)
>
> So, do we have any volunteers? =) -- justin
Woah woah woah...let's not be too hasty here. Just another week or so
and we'll have the APR mission settled and have a solid target where
this will go in Commons (or not). I'd be much happier to move things
around after we know what we're moving out of and where we're moving to,
since otherwise we're just strong arming this out of APR (which is an
act I'm strongly opposed to). Patience. :).
-aaron
Re: Moving serf to commons?
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Nov 04, 2002 at 12:42:24AM -0800, Justin Erenkrantz wrote:
> Does anyone want to spearhead moving apr-serf to commons?
>
> While I want to move it, I don't have the necessary karma/knowhow to
> do that, and I'd rather spend what little time I do have to spend on
> serf writing more code. (Next on my list is deflate support.)
>
> So, do we have any volunteers? =) -- justin
I can definitely do it, but Aaron's being a butthead with a -1 saying it
doesn't fit the Commons' goals :-) Aaron: if you say "no", then what still
needs to happen to define those goals? Help out here, so we can get
component adoption going. I believe Peter wants to start shifting a bunch of
Avalon components, too. There may be some J-C guys, too.
But about serf specifically, I haven't seen votes on it from Ken, Jim, or
Geir. We also don't seem to have a solid consensus on CVS organization or
mailing lists.
Hmm. Maybe we should use Subversion? We could certainly not worry about
directory organization in that case. We'd lose CVS history, though, since we
can't blend multiple CVS repositories over time. i.e. we could use cvs2svn
for an initial set, but future additions would lose history since we
couldn't "blend" them into an existing repos.
[grrr...]
I think it is time to stop dicking around, complete the Commons' mission
statement, and start getting some work done.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
RE: Moving serf to commons?
Posted by Sander Striker <st...@apache.org>.
> From: Justin Erenkrantz [mailto:jerenkrantz@apache.org]
> Sent: 04 November 2002 09:42
> Does anyone want to spearhead moving apr-serf to commons?
>
> While I want to move it, I don't have the necessary karma/knowhow to
> do that, and I'd rather spend what little time I do have to spend on
> serf writing more code. (Next on my list is deflate support.)
>
> So, do we have any volunteers? =) -- justin
Me peers at the man with the karma...
Sander