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

[TOKUNAGA Hiroyuki]

I'm sorry for my late replying, too...

On Sun, 26 Dec 2004 03:48:25 +0900
Masahito Omote <omote at t-base.ne.jp> wrote:

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

Sorry, I didn't understand 'as doing in uim-custom interfaces'. What did
you mean?


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

Prefix is customizable, is it not enough? i.e. ./configure
--prefix=$HOME/uim seems sufficient for me.


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

Thanks a lot!


> > >  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 think that what should be unloaded is deterministic. i.e. All unused
module should be unloaded. So IMHO we don't need unloading 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:
> 
> Is this list is used in im-switcher?

No. What input methods are available or not depends on bridge and
locale. For example, you can't use uim-py with uim-xim and if locale is
ja_JP.eucJP. So im-switcher can't use statically defined input method
list. Legacy encoding support is very important in Japan ;-)


Regards,

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