[SCIM] Re: Design philosophy and strength of uim

[YamaKen]

Slightly offtopic:

I think that the design of SCIM's proxy-style architecture is
reasonable to implement client-server functionality. The
implementation enables IMEngines to run within client
application process or run on scim server according to runtime
dynamic configuration. And the design requires less learning
cost to the client-side programmer because IMEngine interface
transparently handles socket communication.


At Fri, 25 Jun 2004 10:03:09 +0800,
james.su at gmail.com wrote:
> 
> Hi,
>   SCIM is very flexible. It can be act as a pure library as well as a
> C/S structure (like iiimf). You may see these two picture:
> 
> http://freedesktop.org/~suzhe/screenshots/scim-structure-local.png
> http://freedesktop.org/~suzhe/screenshots/scim-structure-cs.png
> 
> The first picture demonstrates a single process scim xim server. All
> IMengines and a x11 FrontEnd object are running within one process,
> which acts as a xim server. The GUI Panel runs as a separated process.
> 
> The second picture demonstrates a C/S like usage. All real IMEngines
> and a socket FrontEnd object are running within one process, which
> acts as a socket server daemon. A socket IMEngine and a x11 FrontEnd
> object are running within another process, which acts as a xim server
> and get input method services from the first process. A gtk2
> application with scim's gtkimmodule is another client of the first
> process. There is only one GUI Panel process which provides gui
> services for all scim process (including the gtk2 apps with scim's
> gtkimmodule.)
> 
> scim-uim with uim can be an IMEngine object in the first process.
> 
> Regards
> James Su
> 
> On Thu, 24 Jun 2004 19:03:24 +0200, David Oftedal <david at start.no> wrote:
> > 
> > James Su wrote:
> > > Hi,
> > >  I think 'semantic API unification' is not so simple, because there are
> > > too many differences between uim and scim, for example:
> > >  1. scim uses one api process_key_event to handle both key press and key
> > > release events. uim uses two.
> > >  2. scim uses show/hide/update methods for preedit string, while uim
> > > uses clear/pushback/update, these are very different.
> > >  3. the candidates api of scim and uim are also very different.
> > >  4. etc. etc.
> > >
> > >  The code base of scim and uim are both very large, changing scim and
> > > uim into a set of similar api may affact very large amount of code.
> > >  So I think wrapper (binding) is easier and better way, just like what
> > > scim-uim does (only about 700 lines).
> > >
> > >  But the most important, you had better to try scim-uim first.
> > >
> > > Regards
> > > James Su
> > 
> > Another issue is how SCIM aims to be compatible with XIM and is run via
> > a backend application, while UIM is just a library which aims to be
> > implemented directly in the APIs that use it (like Qt and GTK). If SCIM
> > and UIM were to merge, one would have to abandon one of those two goals,
> > or combine them in some way.
> > 
> > In that way, I think both UIM and SCIM have an advantage over the
> > other... UIM can be used without running a backend process, while SCIM
> > gives a nice unified interface with an organized menu that's accessible
> > from almost anywhere.

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