From dev-return-2541-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Fri Jun 08 10:17:25 2001 Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 85668 invoked by uid 500); 8 Jun 2001 10:17:18 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 85629 invoked from network); 8 Jun 2001 10:17:14 -0000 From: "Sander Striker" To: "Greg Stein" Cc: Subject: RE: SMS stuff Date: Fri, 8 Jun 2001 12:25:39 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20010608031657.M23560@lyra.org> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N > 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