Return-Path: Delivered-To: new-httpd-archive@hyperreal.org Received: (qmail 22949 invoked by uid 6000); 19 Dec 1997 19:16:05 -0000 Received: (qmail 22943 invoked from network); 19 Dec 1997 19:16:04 -0000 Received: from twinlark.arctic.org (204.62.130.91) by taz.hyperreal.org with SMTP; 19 Dec 1997 19:16:04 -0000 Received: (qmail 5933 invoked by uid 500); 19 Dec 1997 19:22:42 -0000 Date: Fri, 19 Dec 1997 11:22:42 -0800 (PST) From: Dean Gaudet To: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= cc: new-httpd@apache.org Subject: Re: "locale" project In-Reply-To: Message-ID: X-Comment: Visit http://www.arctic.org/~dgaudet/legal for information regarding copyright and disclaimer. Organization: Transmeta Corp. MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: new-httpd-owner@apache.org Precedence: bulk Reply-To: new-httpd@apache.org On Fri, 19 Dec 1997, [KOI8-R] =E1=CE=C4=D2=C5=CA =FE=C5=D2=CE=CF=D7 wrote: > In first place I don't understand why Apache itself (not modules) need to > be under locale !=3D "C", do you have some examples? I.e. if you need jus= t > localized strftime() output just fork once with specific locale at the > Apache startup and pass all locale-specific requests to forked process.= =20 > Shared memory or mmap gives almost no overhead in this situation. In thi= s > model we have just one process per locale used. I am against runtime > locales switching inside Apache core because it cause too much overhead.= =20 I'm against runtime switching of locales as well. In fact all we need is the C locale and whatever other locale the local user wants -- I listed two PRs where the user wants their own locale for things like mod_php and mod_include when formating dates for sending to the client. Since we need only C and "one other" locale I think we could get away with implementing specifically the set of locale functions we use, and using the system's own setlocale() for whatever "true" locale the user wants to use. What a mess. An alternative is to say to these users "tough, C is all we support". Can some of the mod_php folk explain maybe why users need the locale functionality? I think I know why... but a specific example would be good :) > > The C library is poorly designed, POSIX isn't helping it at all. We > > pretty much have to replace all the string and allocation functions > > because we need better resource management and more functionality. It'= s a > > similar step to start replacing the locale functions because we need > > better locale management.=20 >=20 > It is almost impossible to replace locale functions, although locale call= s > are mostly standartized per POSIX, even call arguments (locale names) are > not standartized and locale data itself is _very_ different from system t= o > system... Yeah... you're right. But we could provide locale C specific functions -- and maybe we can even do it in a way that a server can be built with the option of using only locale C, or using C and one other.=20 > I understand your portability intention but it leades to Apache Operating > System(TM) as result running on dedicated machine with nothing else. It > seems there is no good solution of this problem. I hope it not happens i= n > nearest future.... It sucks... but we're not the first to go down this road. qmail uses essentially nothing from man section 3, it has a library of its own which is more suited to writing secure applications. I'd like to see Apache move this way as well... and as we replace string and alloc functions we venture further and further away from libc. > > One more thing to add: locale is a global setting, in a threaded port = we > > can't switch locales at all.=20 >=20 > Maybe will be good to ask someone from POSIX committie about their > locale-related plans. Yeah, but I always get confused by all the different subcommittees.=20 Hey C++ folks, is this solved in any magic C++ class library? Ick, I don't want to bloat us further by going to C++ ;)=20 Dean