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

[YamaKen]

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)

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.

-------------------------------
YamaKen  yamaken at bp.iij4u.or.jp