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

[James Su]

Yes, I agree with you.

In future, SCIM, UIM and IIIMF teams should work together for an unified 
API.

Yes, scim-uim is just a short term solution, but it's the easiest 
solution for endusers right now.

I don't know if it's easy to share codes between scim and uim. scim uses 
it's own architechture (includes socket communication, config store 
etc.) in its components, it's almost impossible to split a piece of code 
without linking to libscim.

Regards
James Su

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