[wrowe@rowe-clan.net: RE: The iconv solution?]

[Greg Stein <gs...@lyra.org>]

[resending...]

----- Forwarded message from "William A. Rowe, Jr." <wr...@rowe-clan.net> -----

From: "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject: RE: The iconv solution?
To: "'Greg Stein'" <gs...@lyra.org>
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:gstein@lyra.org]
> Sent: Friday, December 08, 2000 5:33 PM
> To: dev@apr.apache.org
> 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, rbb@covalent.net 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:wrowe@rowe-clan.net]
> > > > 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                        	rbb@apache.org
> > 406 29th St.
> > San Francisco, CA 94131
> > 
> --------------------------------------------------------------
> -----------------
> 
> -- 
> Greg Stein, http://www.lyra.org/
> 

----- End forwarded message -----

-- 
Greg Stein, http://www.lyra.org/