[Uim] Design philosophy and strength of uim

[James Su]

Hi,
  In brief, SCIM is an input method develop kit (platform or framework), 
like IIIMF, but has many differents. SCIM itself don't provide any 
language conversion engine (except the rawcode engine). It provides very 
simple programming interface and handy utility functions to simplify the 
development of language conversion engine.
  Unlike the philosophy of IIIMF, I think the input method engine should 
not know anything about GUI interface, so in SCIM the IMEngine are 
completely separated with the GUI Panel. An IMEngine only handles the 
algorithm of input logic, so it can be very small and effect, and system 
independent. The FrontEnd of SCIM also does not touch anything about the 
GUI interface, it's only in charge of the input method protocol and 
client interface, like XIM, gtk2 immodule, qtimmodule (future) and IIIMF 
(future).
  In my point of view, the appearance of input method GUI should be 
unified for all input method engines to give users unified "look and 
feel". It makes the input methods very easy to use.
  IMEngine and FrontEnd are binded with signal-slots, because it's very 
loose binding, we can implement FrontEnd without much restrict. For 
example X11 FrontEnd and SCIM gtk2 immodule are very different, but they 
are all FrontEnds.
  The communication between FrontEnds and GUI Panel are via socket (unix 
or tcp). So we also can implement independent GUI Panel component very 
flexible. There are already an alternative Panel which depends on 
KDE/QT, named skim.

-  The design philosophy of SCIM are:
  * very simple api with good flexibility.
  * extensible and dynamic architecture.
  * Separate IMEngine, FrontEnd and GUI Panel completely.
  * loose binding between components.
  * socket communication protocol is not the core part  (not like 
IIIMF), but can be provided as a component.

- The feature of SCIM:
  * Implemented with C++/STL, given SCIM very simple and efficient API.
  * Provides many handy functions to help simplify the IMEngine development.
  * Can act as a pure library based input method backend as well as a 
Client/Server input method architecture (like IIIMF).
  * Simple and powerful IMEngine interface which make it very easy to 
write binding for other input method libraries, like m17n and uim.
  * GUI Panel with rich features to make it acceptable for most of the 
IMEngines.

- 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?)
  * implement an unified C binding API for SCIM's IMEngine interface.

Regards
James Su

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.
>
>-------------------------------
>YamaKen  yamaken at bp.iij4u.or.jp
>
>_______________________________________________
>uim mailing list
>uim at freedesktop.org
>http://pdx.freedesktop.org/cgi-bin/mailman/listinfo/uim
>
>  
>