Is dbus good for heavy applications?

[Huang Peng]

在 2008-04-01二的 09:14 -0400，Colin Walters写道：
> On Tue, Apr 1, 2008 at 2:55 AM, Huang Peng <phuang at redhat.com> wrote:
> > Hi DBus hackers,
> >
> >  I am designing a new IM (input method) platform. I am considering using
> >  dbus as transport layer in the IM platform. The platform will provide
> >  input services for applications for CJK and other non English users. In
> >  the platform, when users type the keyboard, applications will send key
> >  events to IM manager (the dbus service), and then the IM manager will
> >  translate input key sequence to unicode chars and send them back to
> >  applications. In this use case, user will press about 30 to 120 key in
> >  one minute. The service will reply results to application about 60 ~ 240
> >  times in one minute. I don't know whether dbus is proper for this heavy
> >  use case. Can somebody tell me the performance of dbus and give me some
> >  suggestions?
> 
> My guess here is that the problem in this is round trips; e.g. if on
> pressing a single key
> it goes from:
> 
> X server -> application -> session bus -> IM platform service ->
> session bus -> application -> X server
> 
> That could be expensive.  You could cut it down by having the
> application open a direct DBus unix socket channel to the IM
> service, avoiding the session bus.  See DBusServer in the docs.

Your suggestion likes:

 X server -> app -> Dbus channel & IM Platform service (in one process)
-> app -> X server. The IM platform service will be in a local dbus
channel that is started by IM platform self. Right?

Actually, I didn't mention the IM engines. In my architecture, IM
platform service will manager IM engines that are dbus service too.
Client applications can get IM engine services information from IM
platform service, and communicate with IM engines via IM platform
service or via dbus directly. It can not avoid a long round trips. :( 
In old IM platform (like SCIM), the platform loads IM engines from
shared modules. It is more effective, but every engines can impact each
others and the IM platform especially a lot of engines installed, and we
can not start or shutdown a single IM engine easily. So in new platform,
we want to separate engines from platform. it's our situation.

> 
> I'd mention this project on say gtk-devel-list and get feedback about
> your proposed architecture.

I just subscribed gtk-devel-list. Wish can receive more feedback.