Re: Japanese input (was RE: tlug: Japanese)

["Jonathan Byrne" <jpmag@example.com>]

-----Original Message-----
From: Kazuyuki Okamoto <ikko-@example.com>

>The Japanese Input Method is a Server-Client type system.

I don't think there was any question about that, but you
chart illustrates my point exactly: that the Linux/Unix
world has too many clients and too many servers.

The chart on some popular proprietary OSes looks like this:

Server                  Client               Application
------                  ------               -----------
Apple Japanese server   Apple input method   Hundreds

OS/2 Japanese server    OS/2 input method    Not as many as
Apple

MS Japanese server      MS input method      Hundreds

Your chart (next) shows very well the much more confused
picture that we face when using Linux/Unix:

>Server --------- Client ----------------------------------
Application
>cannaserver ---- kinput2 (with canna support) ------------
netscape
>            ---- onew (included jvim with canna support) -
jvim
>            ---- canuum ----------------------------------
mule
>Wnn(jserver) --- kinput2 (with wnn support) --------------
dp/note
>             --- uum -------------------------------------
>             --- onew (included jvim with wnn support) ---
>             --- xwnmo - X -------------------------------


This is exactly why I think it's so important for the major
players in this area to form a group for the purpose of
coming up with just one standard (and ideally, just one
server and one front-end processor).  Unfortunately, the
very fact that this kind of fragmentation exists is a
powerful argument against the chances of such a group coming
together.  The cooperative development model has as a whole
served the Linux community very well, but there are some
areas where it also has weak points, such as this one.

If we had just one standard, then we could count on having
any Japanese-capable applications working with it, instead
of the developer having to choose which one(s) to make it
work with, or going to the trouble of coding in support for
each of them.

But like I said before, I don't really expect the situation
to change.  It will be the way it is now for a long time,
maybe permanently.

Cheers,

Jonathan

--------------------------------------------------------------
Next TLUG Meeting: 13 June Sat, Tokyo Station Yaesu gate 12:30
Featuring Stone and Turnbull on .rpm and .deb packages
Next Nomikai: 17 July, 19:30 Tengu TokyoEkiMae 03-3275-3691
After June 13, the next meeting is 8 August at Tokyo Station
--------------------------------------------------------------
Sponsor: PHT, makers of TurboLinux http://www.pht.co.jp