[Uim] Design philosophy and strength of uim

[YamaKen]

Hi James, let's continue the discussion to recognize each other.

At Thu, 24 Jun 2004 21:38:39 +0800,
suzhe at tsinghua.org.cn wrote:
>   I think 'semantic API unification' is not so simple, because there are 
> too many differences between uim and scim, for example:

I had wanted to express 'worthless difference' rather than
'trivial difference'. It's just a misexpression. So I did not
say that 'the unification is easy'.

And you and I are discussing these articles as 'future work'
(i.e. beyond scim-uim), so we can discuss about API alteration,
can't we?

>   1. scim uses one api process_key_event to handle both key press and 
> key release events. uim uses two.

I think that uim's API should be altered to offer standard event
filtering model to client-side programmers.

>   2. scim uses show/hide/update methods for preedit string, while uim 
> uses clear/pushback/update, these are very different.

We should discuss that what model is appropriate for client-side
programmers.

>   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).

I had already read the code of scim-uim before I had started the
opinion exchange, so I know what scim-uim does. Although
scim-uim is valuable and resolves some problems, it's not a
solution for uim developers but a solution for endusers. So we
should discuss further cooperation.

What's the goal of the your 'implement an unified C binding API
for SCIM's IMEngine interface'? Is it intended to be the only
one API of SCIM for client-side programmer? And the C++ API of
SCIM will going to be the API for develpers of IMEngine and IM
infrastructures? If so, wrapper approach for SCIM is
reasonable. In the case, we should discuss physical API
unification for client-side programmers. This enables deeper
cooperation between SCIM and uim without losing each strength.

>   But the most important, you had better to try scim-uim first.

Yes, this was important. Now I have been fixed my opinion (not
the project's opinion).

- scim-uim can be sufficient for current input method features,
  but it prevents to extend experimental API between
  applications and uim, so scim-uim should be only a alternative
  bridge for uim

- SCIM's framework for UNIX desktop and GUI implementations are
  flexible and well-developed than ours, so we should use it to
  offer unified and advanced UI for endusers

- SCIM's panel (including lookup table) may be combine with
  uim's own bridges such as gtk-immodule and qt-immodule without
  scim-uim, so I think that sharing panel handling codes between
  SCIM bridges and uim bridges is reasonable second step for the
  cooperation. To use SCIM's panel as GUI of uim bridges does
  not prevent extending IM API between uim and
  applications. This offers unified GUI (although without
  desktop-wide IM selection) to endusers

- Desktop-wide IM selection problem is remaining for 'without
  scim-uim' approach. But I think that the problem should be
  resolved involving IIIMF's GIMLET/GIMPET

- SCIM's client-server architecture is useful for endusers
  because it prevents application crashing caused by uim, and
  possibly supresses memory consumption of some large IMs. But
  security considerations are required to run uim on the server

- uim-xim can be replaced with SCIM's X11FrontEnd using scim-uim
  because XIM API will not be extended. This unification will
  reduce complex user tips for XIM


uim is also a explorer for experimental input method API, so we
(the uim project) must keep direct interactions between
applications. The 'direct interaction' is not only 'run within
application process' but also 'without other abstraction layer'.

We want to implement advanced features such as following easily.

- commit string with phonetic guidance (aka furigana)
- accessing entire text of client application
- changing input state according to application state
- etc, etc...

Notice again, we want to keep a rapid extensibility for
future. Comprehensive APIset for now is not sufficient. So
scim-uim is not a solution for uim developers. Please consider
our direction.


> YamaKen wrote:
> 
> >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