[Uim] Reorganization of helper API

[YamaKen]

At Wed, 10 Aug 2005 05:50:48 +0900,
tkng at xem.jp wrote:
> 
> On Tue, 09 Aug 2005 02:58:53 +0900
> YamaKen <yamaken at bp.iij4u.or.jp> wrote:
> 
> > And I suggest following renamings to avoid future
> > misunderstanding by another person. Would you consider it?

> > - rename 'message_types' to 'acceptable_types' to indicate the
> >   role of the 'types' rather than detailed spec of it
> 
> I disagree. I aree appending of acceptable, but removing of message is 
> not acceptable from the point of view of understandability.
> 
> How about following?
> 
> int  uim_mbus_get_acceptable_message_types(uim_mbus *mbus);
> void uim_mbus_set_acceptable_message_types(uim_mbus *mbus, int types);
> void uim_mbus_add_acceptable_message_types(uim_mbus *mbus, int types);
> void uim_mbus_remove_acceptable_message_types(uim_mbus *mbus, int types);

It's good enough for me also.

> > 1. Filtering model
> > 
> >   I'm recognized your design as follows. Is it correct?

> >     Only appropriate participant is receive the messages based
> >     on configured acceptable types hold in the mbus daemon.
> > 
> >     For example, a message that has UIM_MBUS_MESSAGE_TYPE_STATUS
> >     is only delivered to uim-toolbar-gtk as follows.
> >   
> >                     +-----------------------+  msg
> >          status msg |                     ST| ----> uim-toolbar-gtk
> >      uim app1 ----> |SE  uim-mbus-daemon  SE| ----- uim app2
> >      uim app3 ----- |SE                     | ----- uim configuration tool
> >                     +-----------------------+
> 
> I don't understand what you meant by the word SE. But my purpose of
> adding the concept of message type is, to use message type for message
> filtering by the message bus daemon.

The 'SE' represents UIM_MBUS_MESSAGE_TYPE_SETTING as 'ST'
represents UIM_MBUS_MESSAGE_TYPE_STATUS. The figure represents
uim-mbus-daemon process is holding the statuses for each
connection.

What I want to confirm by the question is that the meaning of
"message filtering by the mbus daemon" is not different between
you and I. I had caught the doubt when you commented to bug
#3620. It may be an unnecessarily worries.

> > 3. Common message parser utility functions
> > 
> >   I think that the API revision is a chance to make the message
> >   parser implemented in each bridges unified into standard one.
> 
> I think creating message parser is a good idea, but I don't want to
> implement. I want to use my time for other improvement such as key
> event extention.

Okay. We shall write it someday after 0.6.

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