Pluggable module support in uim(was Re: [Uim] Will you upload daily snapshots of UIM?)

[James Su]

Hi,
  Maybe you should have a look at the design of scim to see how does 
scim support modules. I have a plan to write a scheme imengine for scim 
to enable writing input method for scim with scheme directly. However 
scim-uim + uim is just an implementation.

  I'm just thinking if it's possible to use a standard (unified) C API 
as the glue layer. So imagine, all im modules in uim uses such API, and 
uim, scim and other frameworks (iiimf etc.) both support loading such 
modules. Then scim can provide a module to support such API, uim can 
make use of any scim input methods by loading such module. Is it amazing 
enough?

  I'll post a proposal in the next mail.

Regards
James Su

TOKUNAGA Hiroyuki wrote:

>Hi,
>
>On Wed, 15 Dec 2004 02:18:34 +0900
>Masahito Omote <omote at t-base.ne.jp> wrote:
>
>  
>
>>On Tue, 14 Dec 2004 17:36:54 +0900
>>TOKUNAGA Hiroyuki <tkng at xem.jp> wrote:
>>
>>    
>>
>>>BTW, I think 'module' is better word than 'plugin', how do you
>>>think, Masahito?
>>>      
>>>
>>I have no preference between them. But we have to discuss the detail
>>of the implementation. (In this mail, I use 'plugin' for now.)
>>    
>>
>
>Thanks. Sure, we need discussion. I leave module/plugin name problem for
>now.
>
>
>  
>
>>0) Basic design
>> As you know, opnions about the treatment of Scheme and C is divided
>> between comitters. That is whether Scheme and C should be tightly
>> bounded or not in uim. So which way we choose, plugin's approach is
>> drastically changed. (In svn repository, I take the latter design.)
>>    
>>
>
>I take a stance that they shouldn't be tightly bounded. IMHO we should
>sandwich scheme layer between C layer. (Currently, IM side have to use
>scheme. I want to make 'input method could be written in C only, but of
>course use scheme should be allowed'. To be honest, I'm thinking we
>should reimplement base library with C, but this discussion about this
>is waste of time, obviously we have no such human resource.)
>
>  
>
>> If we take the former, shared library only prepare simple scheme
>> binding from C/C++ or fully implement by Scheme and only implement
>> dlfcn functions by C.
>>  a) Prepare the simple binding to the libraries.
>>   RkBgnBun in libcanna for example.
>>   static LISP canna_rk_bgnbun(LISP _cxnum, LISP _yomi, LISP _maxyomi,
>>   LISP _mode){
>>      int cxnum = uim_scm_c_int(_cxnum)
>>      ...
>>      ret = RkBgnBun(cxnum, yomi, maxyomi, mode);
>>      return uim_scm_intern_c_int(ret);
>>   }
>>  b) Prepare the binding to dlopen, dlsym, dlclose and dlerror only.
>>  All operations
>>     are written in Scheme.
>>
>>     (load-plugin "libcanna.so")
>>     (dlsym 'canna-rk-bgnbun "RkBgnBun")
>>     ...
>>     (canna-rk-bgnbun '(cxnum yomi maxyomi mode))
>>
>> If we take the latter, we simplify Scheme codes and operate to some
>> extent in C.
>>
>>But I have already implemented in the latter. So following sections
>>are expected to the latter.
>>    
>>
>
>For me, it seems that scheme and C are tightly bounded in both of a) and
>b). In the latest svn, we have former solution. In addition, I want to
>propose other solution c).
>
>   c) Provide C interface for input method. We can write input method
>       with C only (if we want).
>
>    For this way, we should provide some C interface for scheme function,
>   such  as register-im, im-commit, and so on.
>
>
>  
>
>>1) Loading plugin
>> o Only load shared library or load .scm at the same time
>>   Current code only load shraed library but I think uim have to load
>>   Scheme code at the same time.
>>
>> o Plugin's path and loading order prioriy
>>   I'm implementing them as follows:
>>     a) 'LIBUIM_PLUGIN_DIR' for all users but mainly for developers.
>>    
>>
>
>Maybe this should be enabled when --enable-debug=yes.
>
>  
>
>>     b) ~/.uim.d/plugins/ for each users.
>>    
>>
>
>Is this really need? I couldn't imagine a situation which need this
>directory.
>
>  
>
>>     c) $libexecdir/plugins/ for all users.
>>
>>2) Unloding plugin
>> o Unloding plugins is not supported at all. If we implement it, we
>> have to take more care of unbounding symbols. If not completed, 
>> segv may happen.
>>
>>   Of couse, not to support plugins unloading is one of the choise.
>>    
>>
>
>I want to support dynamic unloading.
>
>  
>
>> o Implement plugins unloding dialog in uim-pref.
>>    
>>
>
>I don't think this dialog is need. Probably image of the plugin is
>different between I and you. For me, input method = plugin + scm. For
>example, m17n-lib support is now consist from 2 files, libuim-m17nlib.so
>and m17nlib.scm.
>
>I agree with you if you are saying about IM enable/disable dialog.
>
>I want to implement a list of immodule like /etc/gtk-2.0/gtk.immodules.
>i.e. a list of input methods, each input method has infomation about:
>
>  - name
>  - catalog name for gettext (is this need? should input method
>     always use dgettext?)
>  - short desctiption of input method
>  - available language
>  - supporting character encodings
>  - filename (Scheme or plugin. Both of them are of course OK.)
>
>
>
>Regards,
>
>  
>