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

[TOKUNAGA Hiroyuki]

On Tue, 11 Jan 2005 00:35:00 +0900
YamaKen <yamaken at bp.iij4u.or.jp> wrote:

> At Sat, 8 Jan 2005 02:17:31 +0900,
> tkng at xem.jp wrote:
> > 
> > On Thu, 06 Jan 2005 03:59:06 +0900
> > YamaKen <yamaken at bp.iij4u.or.jp> wrote:
> > > What you said does not sound as 'like
> > > /etc/gtk-2.0/gtk.immodules'. What you want is in-process data?
> > > Or actually wants a file?
> > 
> > What I want is a file. In previous mail, I wrote my complaint and
> > forgot to write about what I want.
> > 
> > Why I want a file for input method list is that, because I want to
> > know infomation about avairable input methods without load actual
> > plugin (I want call them as 'module', but it's another topic. I'll
> > write a new mail for this.)
> > 
> > That is to say, if there is a list which include infomation about
> > input methods, we don't need to load all input methods at startup
> > time. This will reduce both of startup time and memory consumption.
> 
> I also want such features. Are your requirements as same as mine
> listed below?
> 
> 1. Make what IM should be appeared for user manageable
> 
> 2. Load actual IM file lazily (i.e. selectable but not loaded at
>    startup)

My porpose is only 2. My intention is to make a list of whole available
inpput methods into a file. This file will be updated when users do
"make install". If there are plural plugin directories, this list should
be splitted into two files like:

  /usr/local/share/uim/im-list.scm
  /home/user/.uim.d/plugins/im-list.scm

Merit of this way is, we don't need to load all input methods to get a
list of available input methods. Because my intension is to make a whole
list, I stick that "list should be update at installation time". If we
could do this with uim-custom, I don't stick to dedicated file.


> I think that we should implement such features by Scheme and
> uim-custom facility as below, to simplify the implementation.
> 
> - The enabled IM list is managed and stored as an ordered-list
>   custom variable rather than dedicated file
> 
> - Generate stub-IM for each enabled IMs. And they load actual IM
>   file and set its own handler procs once its init-handler has
>   been invoked. This provides lazy loading feature
> 
> - IM infomation provided by stub-IMs can be accessed by ordinary
>   uim APIs such as uim_get_im_name(). The lazy loading process
>   is transparent for libuim users
> 
> It may be implemented by few amount of Scheme codes, and we can
> use bridges, helpers and libuim core without change.


Regards,

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