Date: Fri, 22 Dec 2000 01:36:36 +0900 (JST) From: Noriyuki Soda <soda@sra.co.jp> To: core@XFree86.Org, haible@ilog.fr Cc: bsd-locale@hauN.org, i18n@freebsd.org, i18n@XFree86.Org, li18nux@li18nux.net, tech-x11@netbsd.org, tech@openbsd.org Subject: Re: [I18n] Xutf* and friends Message-ID: <200012211636.BAA13471@srapc342.sra.co.jp>
next in thread | raw e-mail | index | archive | help
Bruno Haible <haible@ilog.fr> wrote: > If your functions then are more elegant to use than Xutf8* we can > remove the Xutf8* functions. Bruno, I think you are talking as one of XFree86 developers. (IIRC, you were not core team member...) Is this right? If so, I suppose you makes little of influence of removing public APIs from shared object. Whenever a public API is removed from a shared object, the major number of the shared object should be incremented to keep ABI. This means that binaries which were linked with the shared object of previous major number do not work with new (major-number-incremented) shared object (due to the difference of the major number). If there were commercial/third-party binaries which were linked with the shared object of the previous major number, OS vendor should ship the previous shared object too, to make such binaries work. This is why commercial UNIX vendors almost never remove their APIs, even the APIs are legacy. This is why adding a API to Xclient-side core library requires more attention than adding a feature to Xserver-side. This is why many people worried to add not-so-mature Xutf8* APIs to release version of core X11 library. This is why I thought that only XFree86 core team is responsible to remove APIs, and to increment major number of shared object. -- soda To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-i18n" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200012211636.BAA13471>