[Uim] Design philosophy and strength of uim

[YamaKen]

Hi James, sorry for late reply.

I'm still having problem to run scim-uim, so I can't comment
about GUI component sharing between SCIM and uim. So I only
comment to future work for now.

At Mon, 21 Jun 2004 23:12:46 +0800,
suzhe at tsinghua.org.cn wrote:
> - The future work to unify the input method interface:
>   * extend SCIM's IMEngine/FrontEnd interface to support complex 
> features like Microsoft's TSF. (I know nothing about TSF, do you have 
> any documentation?)

I think that TSF is not a feature but a different model. The
distinction is important.

I'm also having insufficient knowledge about TSF, but a TSF
input method programmer had introduce the technology to me as
below (may contain my misunderstanding).

- applications export 'text store'

- pluggable 'text services' can access and rewrite several 'text
  store' through TSF manager

- accessing to 'text store' is transactional like a database. a
  transaction has transaction ID, and may be aborted. This
  allows simultaneous access to one text store

- 'text service' can be implemented as an input method

- committing of input method is modeled as rewriting text
  store of application at cursor position

See following page for further information.

http://msdn.microsoft.com/library/library/en-us/tsf/tsf/text_services_framework.asp

I think that above processing model is useful to enable some
advanced input method implementation such as Japanese kana-kanji
conversion system based on a recognition of entire text that
client application has (possibly megabytes of).

But I also think that now is not the time to introduce such
processing model into uim or SCIM. We should focus on the short
term goal, completing useful input method environment for now.

What to do for now is to keep in mind the different model.

Once the model is required in the future, uim can eaisly follow
such changes using following strength. 

  * allows rapid scrap & build of core library using flexibility
    of Scheme, well-balanced pragmatism, and in-process tight
    relationship with client

The strength is important value of uim for me. Yes, the way
seems dirty from the viewpoint of SCIM or IIIMF, but I need this
strength to implement advanced input method involving client API
extension. I don't expect that my opinion is recognized
soon. You and I will need more opinion exchange to know each
other.


FYI: Microsoft is planning another input system for Longhorn.

The "Avalon" Input System
http://msdn.microsoft.com/longhorn/default.aspx?pull=/library/en-us/dnlong/html/avaloninput.asp

>   * implement an unified C binding API for SCIM's IMEngine interface.

Good direction! I hope that the C binding simplifies input
method programming for client-side programmer. I suggest one
additional development step before making the binding. The step
is 'semantic API unification' I called.

I think that SCIM's IMEngine instance and uim's uim_context is
similar, but having some trivial difference such as following
example. The difference brings learning cost and confusion to
client-side programmer and costs boring work.

  SCIM:
  virtual bool process_key_event (const KeyEvent &key) = 0;

  uim:
  int uim_press_key(uim_context uc, int key, int state);

The two function may be more similar as below.

  SCIM:
  virtual bool filter_key_event (const KeyEvent &key) = 0;

  uim:
  int uim_filter_key_event(uim_context uc, const KeyEvent *key);

The names is example for example. We should select appropriate
names that forms good mental model into client-side programmer.

Following effect is intended for the work.

- offers unified simple input method programming model for
  client-side programmer to popularize input method capability
  to applications (or toolkits). our promotion effort will also
  be unified

- developer document for client-side programmer can be (partly)
  shared with uim, at least overview of programming model

- possibly brings several uim bridges such as console, Mac OS X,
  Qtopia (Zaurus), and so on to SCIM although some thin wrapper
  may be required

The semantic API unification makes SCIM C binding closer to uim,
so we get broader cooperation possibility. As I mentioned above,
I want to keep direct interaction with client application for
future. But I also think scim-uim is useful option for users, so
I want to make both the way happier with consistency. The
unification helps this, maybe.


Please wait for my opinion about GUI cooperation between SCIM
and uim.


> YamaKen wrote:
> 
> >Hi folks, I'm now trying to discover what the uim is.
> >
> >Although uim is known as an useful software, the philosophy is
> >not known well. Considering recent circumstances of uim
> >involving SCIM, IIIMF, and immodule for Qt, we should explain to
> >the community what is the value we want.
> >
> >Following is a my personal opinion about uim. Other uim
> >developers may have completely different view, so please let me
> >know! Especially Tabata-san must have a deeper opinion about
> >security.
> >
> >
> >- design philosophy
> >  * simple & efficient
> >  * be clean for valuable things
> >  * be pragmatic for unimportant problem
> >  * refuse generalization for generalization
> >  * keep simple to follow the requirements beyond input method
> >
> >- strength
> >  * allows rapid scrap & build of core library using flexibility
> >    of Scheme, well-balanced pragmatism, and in-process tight
> >    relationship with client
> >
> >  * (security considarasions will be here)
> >
> >  * offers easy-to-use simple programming model to client (apps
> >    & bridges) programmers
> >
> >  * offers flexible programming platform using Scheme to backend
> >    (input method) programmers
> >
> >  * requires few resources
> >
> >  * supports broad-range platforms such as UNIX desktop, Mac OS
> >    X, PDA, Embedded platforms with poor resources, possibly
> >    cell-phones, game console, digital-appliances, etc.
> >
> >- what is not acceptable
> >  * to lose above strength
> >  * (security considarasions will be here)
> >
> >- what is acceptable
> >  * to embed uim as a conversion engine of another framework if
> >    original security consideration is preserved. although the
> >    scheme is acceptable, this is regarded as 'alternative
> >    bridge implementation' for now
> >
> >  * discontinue and merge several non-core components such as
> >    bridges, applets, GUIs with corresponding one of external
> >    project
> >
> >  * alter the client API to be (semantically) unified with the
> >    another API of external projects to offer unified
> >    programming model to client-side programmers
> >
> >  * unifying the efforts with external projects that popularize
> >    input method capability (with CJK considerations) to
> >    client-side programs
> >
> >Attention again, the opinion is not of the project but my
> >personal one.
> >
> >Note that, 'beyond input method' is intended to suppose a newer
> >technology like Microsoft's Text Services Framework that has more
> >generic and different model rather than input method model.
> >
> >
> >SCIM developers, let's start exchanging opinions each other. We
> >would like to know the philosophy of SCIM as second step (of
> >course at the scim at freedesktop.org). I believe that we are going
> >to actualize good thing for all participant of input method
> >world.
> >
> >Discussions and questions are welcome.

Regards,
-------------------------------
YamaKen  yamaken at bp.iij4u.or.jp