[Uim] Reorganization of helper API

[TOKUNAGA Hiroyuki]

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?
> 
> 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

I agree.

> - 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);


> 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
>                     +-----------------------+

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.


> 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.

I want to keep current message formats. I think current helper protocol
is still room for improvement, but that's another topic. Altering two
things at the same time is not a good idea.


> 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.


Regards,

-- 
TOKUNAGA Hiroyuki
tkng at xem jp