[Uim] Reorganization of helper API

[YamaKen]

At Sun, 7 Aug 2005 19:33:56 +0900,
tkng at xem.jp wrote:
> 
> On Fri, 05 Aug 2005 19:26:14 +0900
> YamaKen <yamaken at bp.iij4u.or.jp> wrote:
> 
> > At Wed, 3 Aug 2005 01:44:00 +0900,
> > tkng at xem.jp wrote:
> > > int  uim_mbus_get_message_type(uim_mbus *mbus);
> > > void uim_mbus_set_message_type(uim_mbus *mbus, int type);
> > > void uim_mbus_add_message_type(uim_mbus *mbus, int type);
> > > void uim_mbus_remove_message_type(uim_mbus *mbus, int type);

> > I guess that it is designed for filtering messages by type at
> > the server process, instead of reflecting all messages to all
> > processes as helper-server does. Is it correct?
> 
> Yes.

> Get/set are fundamental, add/remove are utility. Here is an example of
> rest get/set function.

> enum uim_mbus_message_type
> {
>   UIM_MBUS_MESSAGE_TYPE_STATUS  = (1 << 0),
>   UIM_MBUS_MESSAGE_TYPE_INPUT   = (1 << 1),
>   UIM_MBUS_MESSAGE_TYPE_SETTING = (1 << 2),
>   UIM_MBUS_MESSAGE_TYPE_FOCUS   = (1 << 3)
> }

Thanks. My question have been cleared.

And I suggest following renamings to avoid future
misunderstanding by another person. Would you consider it?

int  uim_mbus_get_acceptable_types(uim_mbus *mbus);
void uim_mbus_set_acceptable_types(uim_mbus *mbus, int types);
void uim_mbus_add_acceptable_types(uim_mbus *mbus, int types);
void uim_mbus_remove_acceptable_types(uim_mbus *mbus, int types);

- rename 'type' to 'types' to indicate its multiple type
  capability

- rename 'message_types' to 'acceptable_types' to indicate the
  role of the 'types' rather than detailed spec of it


And I want to understand your design more accurately. Please
let me know following issues.

1. Filtering model

  I'm recognized your design as follows. Is it correct?

  - Current implementation
  
    All participants receives the message from uim app1
    regardless of its type.
  
                    +-----------------------+
         status msg |                       | ----> uim-toolbar-gtk
     uim app1 ----> |   uim-helper-server   | ----> uim app2
     uim app3 <---- |                       | ----> uim configuration tool
                    +-----------------------+
  
  - Your design
  
    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
                    +-----------------------+


2. Message format compatibility

  I'm assuming that all of current helper message formats
  defined as doc/HELPER-PROTOCOL will basically kept. Is it
  correct?

  It's required to keep IM codes unchanged. Of course additional
  feature may change the definition.


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.

  Are you considering it also?


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