[openi18n-im:01522] Re: CommonAux framework design/implementation

Hi, Famao and Karsha,

Please check the attached graph. the Red color part marked as "May
not exists in old

application" should be what we called "CommonAux.so".

See may comments below.

BTW, Famao, could you please let me know how things going on? And
your

ideas about the CommonAux framework, as we talked in Beijing, you
already have

many. :-)

Phill Zhang

AShiZaWa KaZuNoRi :

Hi, Phill,

Would you draw a picture to illustrate how each IIIMF components
and iiimd internal threads interacts each other? The picture
will greatly help me and possibly others to understand your
design and concerns.

Anyway, my comments below.

Date: Wed, 24 Aug 2005 17:48:24 +0800
From: Phill Zhang <[email protected]> :

Hi, Famao,

Sorry for this late communication. My computer was crashed due to last
weekend's power off by the Building. I just has to set it up.

How about the Common Aux framework? Below is what I am thinking
about this issue:

1. IIIMP event content:

typedef struct {
int32 event_type
int32 param
int32 ic_id
const char* aux_name
const char* im_name
uint32 sz
uchar* buffer
} CommonAuxEvent;

2. iml api for IME developer on server side

void iml_aux_draw(session, CommonAuxEvent* e);

^^^^^^^^^^^^^^^^^^^^^^^^^^

It should be iml_common_aux_draw

Would you explain why iml_make_aux_draw_inst() is not enough?
Or do I misunderstand?

No problem. But the iml_make_aux_draw_inst() do not provide byte
buffer. So I need

a warpper, which may at last convert it into iml_make_aux_draw_inst()
or some new event.

But the low level implementation is hidden by the API.

and define a new type of IMevent for IME's call-back function.

This IME means LE?

OK, let's say, it is LE.

3. All Common Aux event comes to CommonAuxManager on the client desktop,
I hope this CommonAuxManager's functionality could be integrated into
the iiim-xbe, or another process
started with X server.

If CommonAuxManager is implemented as a aux.so, then iiim-xbe
can be the manager.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

commonaux.so just communicate with CommonAuxManager. It is only a

lightweight communication proxy, not the CommonAuxManager I mean.

Neigther it should not start the CommonAuxManager, due to different
user

problem.

All CommonAux are started and monitored by CommonAuxManager.
CommonAuxManager forward
the message to the real CommonAux identified by the name. The
communication between them
is not iiimp related.

This is the expected behavior for aux.so.

But currently, maybe some CommonAuxObj.so is needed, which is
responsible for:
1) locat/start (if not started yet) CommonAuxManager on client desktop.

Only when aux.so is loaded by iiim-xbe.

Yes, this is a solution.

2) forward commonAux messages from client to CommonAuxManager
3) receive messages from CommonAux and send it back to client.

I've heard that the implementation will use IM_AUX_DRAW without
changes. Then, I think that using the existing framework has no
problem and less risky. So I'd suggest you to follow aux.so
style for this feature. If you want other style, that may break
current IM_AUX_DRAW semantics.

CommonAux really wants the API to be defined. Let's find in the
graph for those API's:

(1) LE's Aux API
(2) Aux's application API
(3) Inter-Aux communication API, or Aux <---> AuxManager Communication API

In the (1) I really want a byte buffer, since pack/unpack is common, and always
usefull in later processing, like X communication.

We have to make sure that the starter client is of the same user who
start the X server.

Strongly agree. Any other aux processes also need to be own by
the desktop owner.