[openi18n-im:01449] Re: key release issue with iiimxcf

Federic Zhang <[email protected]> Thu, 30 Jun 2005 00:49:01 +0800
Newsgroups gmane.comp.internationalization.input-methods
Message-ID <[email protected]>
Kasha,

Your suggestion and explanation are rather useful, we should take the
compatiblity into consideration no matter whatever we commit, Thanks!

-federic

> Date: Wed, 29 Jun 2005 10:47:44 +0800
> From: Federic Zhang <[email protected]>:
> > 
> > > Date: Wed, 29 Jun 2005 10:19:51 +0800
> > > From: Federic Zhang <[email protected]>:
> > > > Kasha,
> > > > 
> > > > >From LE and IM point of view, KEYEVENT data type isn't incompatibly
> > > > changed, a new member 'member' is appended at end of the original
> > > > KEYEVENT struct, those *existing* LE *binary* can work well with the new
> > > > change.
> > > > 
> > > > The root cause happens in client side, i already sent to alias, i just
> > > > modified iiimgcf, other client frameworks such as iiimxcf and iiimqcf
> > > > should be synced with the change as i amn't familiar with them, i hope
> > > > someone can do it, but nobody step in, but i have to hack by myself to
> > > > incompatibility issue. :(
> > > 
> > > If client frameworks need to be updated, this is the problem.  I
> > > meant compatibility between old version and new version.
> > > Existing client frameworks should be supported by updated server
> > > framework, I'm suggesting.
> 
> I should say:
> 
>   Existing client frameworks should work with updated server
>   framework, without the new feature.  Existing server framework
>   should work with updated client frameworks, without the new
>   feature.
> 
> +------------------------------------------------------------+
> |                  | existing           | new                |
> |                  | server framework   | server framework   |
> |------------------+--------------------+--------------------|
> | existing         | the feature is not | the feature is not |
> | client framework | available          | available          |
> |------------------+--------------------+--------------------|
> | new              | the feature is not | the feature is     |
> | client framework | available          | available          |
> +------------------------------------------------------------+
> 
> All combination should work, I'm suggesting.
> 
> > 
> > I see. Can we update server framework only in this case? IMHO, most of
> > cases, server framework and client framework have to *chorus* together
> > to support one feature.
> 
> 
> > I mean both sides have to be updated. Correct me
> > if my understanding is wrong.
> 
> Yes, right.  To support this feature, both of client frameworks
> and server framework will be updated.
> 
> Thanks,
> -- 
> kasha
> 
> > 
> > -federic
> > 
> > > Thanks,
> > > -- 
> > > kasha
> > > 
> > > > 
> > > > Hope it can clarify.
> > > > 
> > > > -federic
> > > > 
> > > > > Date: Tue, 28 Jun 2005 22:01:54 +0800
> > > > > From: Federic Zhang <[email protected]>:
> > > > > > 
> > > > > > It is caused by iiimxcf, if the attached patch is patched to
> > > > > > iiimxcf/xiiimp.so/iiimp/KeyMap.c, it should work.
> > > > > 
> > > > > I think I understand the root cause.  The implementation of key
> > > > > release feature breaks compatibility.  KEYEVENT data type is
> > > > > incompatibly changed.
> > > > > 
> > > > > So the question is that whether this feature can be implemented
> > > > > in a compatible way or not.
> > > > > 
> > > > > Federic, how do you think?
> > > > > 
> > > > > Thanks,
> > > > > -- 
> > > > > kasha