[SCIM] Re: [Uim] Design philosophy and strength of uim
James Su
suzhe at tsinghua.org.cn
Tue Jun 29 18:38:23 EEST 2004
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.
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.
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
>
>_______________________________________________
>scim mailing list
>scim at freedesktop.org
>http://freedesktop.org/mailman/listinfo/scim
>
>
>
More information about the uim
mailing list