[SCIM] Re: [Uim] Design philosophy and strength of uim

[YamaKen]

At Tue, 29 Jun 2004 23:38:23 +0800,
suzhe at tsinghua.org.cn wrote:
> 
> More feedback:
> 1. The C wrapper of SCIM is just for client interface, just like what 
> uim does. So we may work together for an unified client api.
> 2. The C++ interface is for developing IMEngines and other components of 
> SCIM.

Sounds good.

> 3. There is no security issue in SCIM's socket interface if all things 
> are in one box, because in one box, unix socket will be used, and each 
> user has unique socket file name, and the file can only be read by the 
> owner.

I had intended 'Security consideration' as following, so the
security consideration exists for scim-uim. "it's safe if UNIX
domain socket is used" is too loose to define our policy.

- whether UNIX domain socket MUST be used or SHOULD be used
- whether INET domain socket MUST not be used or SHOULD not be used
- permission issues of server process
- possible vulnerability due to design of the server
- resource isolation between input methods (such as memory space)
- etc, etc...

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

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