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

[TOKUNAGA Hiroyuki]

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,

-- 
TOKUNAGA Hiroyuki
tkng at xem.jp
http://kodou.net/