[Uim] [Docs] About the design of uim

[YAMAMOTO Kengo / YamaKen]

Hi Martin,

At Tue, 17 Apr 2007 15:32:11 +0900,
martin at swift.is wrote:
> 
> On Mon, Apr 16, 2007 at 11:08:14PM +0900, YAMAMOTO Kengo / YamaKen wrote:
> > I've revised the introduction page of the docs about the
> > desctiption about uim's design. Please read it and revise it
> > more appropriate or let me know your opinion about the
> > modification.
> > 
> >   http://en.wikibooks.org/wiki/Uim/Introduction
> > 
> > The design summary is complemented for uim users (not for
> > developers). So the description does not explain about
> > Scheme-related internals, and focused on the difference to other
> > input method software.
> 
> Many thanks for your edit. Not only is it reassuring that someone
> knowledgeable has reviewed it, but you added a lot of good
> information. I took the liberty of rewording it quite a bit, but hope
> that I didn't introduce any inaccuracies. If I did, or changed the
> focus of the text from what you think is better, please let me know!
> 
> In my rewording of the Design section, I emphasized the modular layout
> as a solution to the scalability problem that IMs face. In stead of
> saying that uim is "a library bundled with a number of loadable
> software modules", I said that "[t]he core library interfaces with
> loadable software modules" because uim isn't restricted to the modules
> it comes bundled with. What do you think of this change?

Removing the word 'bundled' is a good change. Thanks. But the
expression "the core library interfaces with loadable software
modules" is a bit inaccurate for current uim design although
future uim will fit to the expression well.

Current libuim is containing not only interfaces and adapters
but also a Scheme interpreter as base facility. Since I think
that containing such dynamic language runtime in the core
library is an important information to recognize the abstract
design of uim, I'm glad if another good expression that implies
it has been found. Do you have any idea?

> In the last paragraph of the section, I felt that it sent an
> unwelcoming message to users, so I reworded in an attempt to say:
> "we're not ignoring users, but giving them a better piece of
> software". In the process, I took the liberty of assuming the reason
> why your emphasis is on productivity. Is this correct:
> 
>   Productivity for input method developers to facilitate high-quality
>   input methods is a high priority for ''uim''.

Correct. Thank you for the rewordings. Yes, my words are too
rough for users as you pointed out, due to the my poor English
vocabulary.

My intension on the words is the way to reach the goal.

The goal of uim is providing useful input method environment for
all participants including users, developers and system
integrators. But since IM-related development sometimes faces
complex and complicated problem or design limitation of current
framework, some improvement requests for end-users require high
development cost if they are written on the current uim
implementation.

On such situation, our development way is:

  1. Reconstruct or create underlying facility at first
  2. Implement new features based on the facility

So we often defer a feature request until the facility for it
has been ready.


For example, our GUI preference editor had been developed on the
underlying uim-custom facility to satisfy following two
requirements.

  - Editing IM preferences easily    (for users)

  - Providing GUI preferences easily (for IM developers)

But following user inconvenience is not resolved until now since
they are classified as "low priority". They should be resolved
in some future, but other issues for IM development are having
high priority than them.

  - It is having a bit ugly widget layouts due to the simple
    automatic layout algorithm

  - Too slow startup

In contrast to the uim's way, scim-anthy had selected layouting
all customization parameters by hand for each GNOME and KDE as
like as ordinary GUI application. Since he prioritized user
convenience than IM development/maintainance easiness, the
higher cost for adding or modifying customization parameters are
reasonably accepted. We probably cannot reach as high as
scim-anthy does for user convenience until uim framework is
matured enough. It came from the difference of development
policy.

> You changed "input method" to "input method framework" and used "input
> method" for what the rest of the documentation has so far referred to
> as "conversion engine". Could you describe what you see as the best
> terminology (and, if possible, why)? I sorely missed your input in the
> terminology discussion.

In my writings, the three terms are used as follows:

  - input method framework

    uim, SCIM, IIIMF

  - input method

    uim-latin, uim-anthy, scim-anthy, uim-canna, scim-canna,
    uim-prime, scim-prime

  - conversion engine

    Anthy, Canna, PRIME

Sorry for my absence in the terminology discussion. I had given
up to follow the discussion thread to grasp the final discussion
status. Could you list up the "all-participants-agreed terms"
and "non-agreed terms" in the discussion?

> PS. Do you have difficulty understanding what I write? A Japanese
> friend of mine recently pointed out to me that my sentences are often
> too long and too complicated. Please let me know.

No. I guess that what he said is politeness on your English
expressions, or redundant mentionings for communication
reliability (such as "in other words ..."). But since they both
are very helpful for technical communications, please keep
current writing style.

Only my non-agile productivity and limited English writing
ability are preventing the documentation improvement. Sorry, and
please don't think all Japanese respond slow like me.

------------------------------------------------
YAMAMOTO Kengo / YamaKen  yamaken at bp.iij4u.or.jp
FAMILY   Given / Nick
http://en.wikipedia.org/wiki/Japanese_name