> -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Carsten Haitzler > Sent: Friday, November 01, 2013 7:29 PM > To: Macieira, Thiago > Cc: [email protected] > Subject: Re: [Dev] [RFC] kdbus transport for DBus > > On Fri, 01 Nov 2013 11:39:05 -0700 Thiago Macieira > <[email protected]> > said: > > > On sexta-feira, 1 de novembro de 2013 09:53:45, Schaufler, Casey wrote: > > > > In order to support applications that haven't been ported, kdbus > > > > will provide a bus converter. That is, it will launch a separate > > > > daemon instead of dbus- daemon that will create the expected > > > > socket addresses and will do on-the-fly translation from the > > > > protocol 1 messages on Unix sockets to protocol 2 messages on kdbus. > > > > > > That sounds likely to eliminate any of the performance gain kdbus > provides. > > > > Correct. > > > > The performance gains are not for non-ported applications. They are > > only valid for applications using D-Bus bindings that get ported. > > > > Porting the main bindings is the first step. Note that there are a > > number of applications -- especially system daemons -- that are not > > using a binding but instead are using libdbus-1 directly. Those need to be > individually ported. > > > > As the QtDBus upstream maintainer, I can tell you it's not a task we > > were looking forward to. It's not going to be easy for us, especially > > considering the only person who does any work on that module is me. > > i feel you man. thus right now the bridge compat daemon is looking good as a > stop-gap to keep us going until the rewrites can be done. in fact chances are > it's not just a rewrite but a need to support BOTH libdbus AND kdbus > depending if the system has been updated to kdbus support yet or not. so it > will require abstracting into a runtime switch (loadable modules perhaps)...
Why do I feel like I'm missing something? We want kdbus to improve performance. Many/most/some dbus applications will require porting. That is too much work, so we need a compatibility daemon that is going to suck away any performance gain, and in fact probably make performance worse. We're counting on the widespread adoption of kdbus in the future, which will get the performance back as everyone ports everything from dbus to kdbus. I can see kdbus as a long term plan. I can't image why it makes any sense at all for Tizen3. I see lots of work and a system that does not perform as well as it does today with "real" dbus. Someone please tell me what I'm missing. > -- > Carsten Haitzler (The Rasterman) <[email protected]> > _______________________________________________ > Dev mailing list > [email protected] > https://lists.tizen.org/listinfo/dev _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
