apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sander Striker" <stri...@samba-tng.org>
Subject RE: SMS stuff
Date Fri, 08 Jun 2001 10:25:39 GMT
> On Fri, Jun 08, 2001 at 11:09:42AM +0200, Sander Striker wrote:
> > > I am well beyond 100% in support of the sms schema.  The only
> > > question is what is which, do we wrap the pool schema in sms,
> > > or do 'pools' become sms?
> >
> > I'll try and write up a comparison between the apis in the weekend,
> > together with how it could be handled _if_ pools are replaced with
> > sms. If after that people are still not convinced *), I'm starting
> > to think 'we've tried. no deal. move on.'.
>
> A short description/comparison may help.
>
> However, I believe that no matter what you may end up describing, the only
> thing that people will be comfortable with is an absolute retention of
> apr_pool_t and SMS growing silently underneath that API. Certain
> applications may choose to use SMS directly (fine!). At the end point,
> apr_pool_t will be a slim cover, and we can choose what to do at
> that point.
>
> > > Greg's argument (and I'm leaning that way) says 'pools are now
> > > widely deployed'.
> >
> > I tend to disagree on that. It is 'only' deployed in httpd and
> > subversion. [not counting apr and apr-util]. If we want to change
> > things like this, now (read this as _after_ the release of
> > httpd-2.0) is the time.
>
> Um. Hello? Have you counted the number of third party modules in
> existence?
> Tossing the pools means tossing the basic framework for a couple hundred
> modules. apr_pool_t and apr_p* will remain (effectively) forever.
>
> It is entirely reasonable to assume that apr_pool_t could be a different
> name for a particular type of apr_sms_t, but there is no effective way to
> eliminate apr_pool_t and its associated functions.
>
> > > Grow a pool into an sms, don't break anyone's code along the way
> > > (by making the default sms our beloved pool schema) and we are in
> > > strong shape.
> >
> > There is a way to do everything _without_ breaking code along the way.
> > I'll include that in the thingy I had planned for the weekend.
>
> Right. I can see this, and it follows what some of us have been
> saying: grow
> the SMS stuff *under* the pool abstraction. Keep pools as the
> top-level API.

Ah, ok, I'll describe what I have in mind. 'old' modules can retain that
api, new ones are advised to move (in my description).

> > *) convinced is not the right word here. I'm more looking for open
> >    to change, but that is also not what I'm trying to say. Damn,
> >    it is hard to express yourself sometimes when you kind find the
> >    words... :-)
>
> Don't worry about it. We're all convinced of particular things. But we are
> all, also open to change. If we were obstinate mother fuckers,
> then we would
> never have received commit privileges. (that is the hope, at least :-)
>
> Open Source is not conducive to stubborn attitudes. People who are
> inflexible tend to be weeded out. But being flexible doesn't mean
> we have to
> /not/ have strong opinions at any point in time.

*grin* I agree.

Got to run now, I promissed to help a friend move. Bye all.

> Cheers,
> -g

Sander



Mime
View raw message