[resending...] ----- Forwarded message from "William A. Rowe, Jr." <[EMAIL PROTECTED]> -----
From: "William A. Rowe, Jr." <[EMAIL PROTECTED]> Subject: RE: The iconv solution? To: "'Greg Stein'" <[EMAIL PROTECTED]> Date: Sun, 10 Dec 2000 12:18:27 -0600 This is done. Attics to be purged at 12:00 PST Monday, so get yourselves into the office on Monday and update your trees :-) I've left the tags, if they are of any use... of course that implies we or the user must checkout apr-iconv as apr/i18n/unix/iconv ... I set up no automagic checkouts, and I'm far from certain we ever want one. I also left alone the issue of whether we build parallel-to apr or within its earlier home. Ideas are welcome. Please wait for appropriate mail list to be created and karmas to be granted before attempting to commit to apr-iconv. > -----Original Message----- > From: Greg Stein [mailto:[EMAIL PROTECTED] > Sent: Friday, December 08, 2000 5:33 PM > To: [email protected] > Subject: Re: The iconv solution? > > > +1 from me! get that big beast outta APR > > I'm not sure about nuking stuff in the repository, though. > Since OtherBill > shoved the mess into the repository before the last alpha > (bad!), they have > now been tagged and were delivered as part of 2.0a8. > > Cheers, > -g > > On Fri, Dec 08, 2000 at 12:15:18PM -0800, [EMAIL PROTECTED] wrote: > > > > My own opinion, and I believe this matches with Bill's is > that we can't > > distribute iconv with APR, because it is just too big. I > would like to > > put stub functions into APR, that can load iconv codepages, given a > > path. This would mean that any program that wants to use > codepages will > > need to prep them first, but that is okay. Then, we put > the codepages > > into the own repository, and create a tar ball that is > accessible from the > > web site. > > > > Ryan > > > > On Fri, 8 Dec 2000, William A. Rowe, Jr. wrote: > > > > > Please comment to this, I think Greg, Jeff, Ryan and I were on the > > > same page on this, but I won't go ahead without a vote. > I'd like it > > > to happen Saturday, since we don't seem to be rolling till Monday, > > > and I'd like to set Mon 00:00 GMT as the last chance to get your > > > tree checked out before we start blasting attics :-) > > > > > > Bill > > > > > > > From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED] > > > > Sent: Friday, December 08, 2000 9:18 AM > > > > > > > > Suggestion, > > > > > > > > It's impossible to maintain the whole of iconv within > the apr tree, > > > > the thing is just too big and harms folks who already have it > > > > installed. > > > > But, since this is a bsd thing that we need to make more > > > > portable, I'm > > > > suggesting we institute its own apr-iconv repository. > > > > > > > > Long term, I'd like to see a portable implementation of the > > > > build for > > > > xlate/iconv/lib housed in apr, that can be statically > linked into apr. > > > > This would eliminate a bunch of code and portability > > > > questions. But the > > > > ces and ccs modules, as folks want them, should be > checked out of > > > > apr-iconv, since they shouldn't pose portability > concerns (or can be > > > > patched if they do). > > > > > > > > If this is agreeable, I'd let someone create the apr-iconv > > > > cvs and I'll > > > > move the sources over there. I'd like to do this today, > > > > before we roll. > > > > > > > > Bill > > > > > > > > > > > > > > > > > > > > > ______________________________________________________________ > _________________ > > Ryan Bloom [EMAIL PROTECTED] > > 406 29th St. > > San Francisco, CA 94131 > > > -------------------------------------------------------------- > ----------------- > > -- > Greg Stein, http://www.lyra.org/ > ----- End forwarded message ----- -- Greg Stein, http://www.lyra.org/
