From owner-freebsd-hackers Thu Oct 19 05:07:29 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA19085 for hackers-outgoing; Thu, 19 Oct 1995 05:07:29 -0700 Received: from expo.x.org (expo.x.org [198.112.45.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id FAA19080 for ; Thu, 19 Oct 1995 05:07:27 -0700 Received: from exalt.x.org by expo.x.org id AA00423; Thu, 19 Oct 95 08:06:56 -0400 Received: from localhost by exalt.x.org id IAA01880; Thu, 19 Oct 1995 08:06:54 -0400 Message-Id: <199510191206.IAA01880@exalt.x.org> To: Terry Lambert Cc: hackers@freefall.FreeBSD.org Subject: Re: xterm dumps core In-Reply-To: Your message of Wed, 18 Oct 1995 19:20:55 EST. <199510190220.TAA01615@phaeton.artisoft.com> Organization: X Consortium Date: Thu, 19 Oct 1995 08:06:54 EST From: "Kaleb S. KEITHLEY" Sender: owner-hackers@FreeBSD.org Precedence: bulk >What Andrey *might* be overlooking is when the X server is FreeBSD >and the client is one of the legacy systems. The X server knows nothing about locale. The server and client do not exchange locale information. Locale is entirely client side data. Clients running on legacy systems use the legacy system locale names for things like calls to setlocale. The legacy system locale name is mapped to the corresponding X locale name in order to load the X locale database, which will be used for things like creating input and output contexts. >> As an aside I would say that I believe all these companies take their >> standards compliance very seriously. Yet none of them have a problem with >> not following RFC 7000 in choosing names for their locales. The switch >> from foo.ISO8859-1 to foo.ISO_8859-1 seems completely gratuitous. The fact >> that he will compound it by failing to have any sort of backwards >> compatibility is inexcusable. >The backward compatability won't be an issue for the Pure BSD environemnt; How naive are you? I know at least two people who don't run a "pure FreeBSD" environment. Andrey and I both use X. The only reason I know that Andrey runs X is because he has broken backwards compatibility and now his xterm dumps core. I believe that the average user thinks he or she can just upgrade FreeBSD and continue using the rest of his or her installed software without change. I don't think that's an unreasonable expectation. Backward compatibility will certainly be an issue for those who don't/can't/won't upgrade their XFree86 with the new XFree86-plus-FreeBSD-2.1-changes at the same time they upgrade FreeBSD. It's all well and good to say that people should just automatically do the upgrade, but one need only look at the molassis-like pace at which people are moving from XFree86 3.1.1 to 3.1.2 as evidence that there is considerable resistance to changes like that. >if X throws around only official names internally for things like font >selection, then he should be safe dropping non-RFC 7000 locales entirely. Define safe. By dropping legacy FreeBSD locale names (in preference for RFC 7000 names) without providing a transitional period during which backwards compatiblity is maintained, he is going to either break a lot of people's work environments, or he is going to force them to upgrade XFree86. That doesn't sound like "safe" to me. Given that all it takes is a few symlinks to maintain compatibility I fail to understand his resistance to it. There is no standard that requires locale names take any particular form. Andrey seems to think that it would be convenient to use names that are in use elsewhere, but in reality he's going to inconvenience a lot of people. His argument that backwards compatibility is bad because it allows users to continue using deprecated names is completely specious. He's just being stubborn and FreeBSD customers are going to suffer for his mule headedness. And FWIW, X does only "throw around" official names. Fonts use XLFD names; XLFD is an X Consortium standard. X locale names are registered names in the X Consortium Registry, the were chosen by X Consortium members, i.e. companies like Sony, Fujitsu, NEC, and Okidata, and OMRON, just to name a few. -- Kaleb