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

[Masahito Omote]

Hi, sorry for my reply becomes late.

On Wed, 15 Dec 2004 17:08:42 +0900
TOKUNAGA Hiroyuki <tkng at xem.jp> wrote:

> > 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.)

I agree with you.

> 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.

Umm, I seem to have been misunderstood. Yes, scheme and C are tightly bounded in
current svn.

I think these mechanisms are needed for plugin's developers as doing in uim-custom
interfaces. If we succeeded in implementing this, we can implement other interfaces
such as perl, ruby, python and etc.

> > 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.

All user cannot always install to ${prefix}/lib/uim/plugins/. (i.e. All
user cannot alway have root privilages.) For example, shared machine in
which uim is already installed in schools, families, etc.... I want to
support for their environments.

> > 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.

OK, but we have to prepare scheme symbol tables or lists which defined
by plugins. I'm implementing scheme code for them.

> >  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.

If we support dynamic unloading, I want to support unloading dialog in uim-pref.
But priority is low for now.

> 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:

Is this list is used in im-switcher?

Thanks,
-- 
Masahito Omote(omote at utyuuzin.net, omote at sapmed.ac.jp, omote at debian.org)