> 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
