On 11/04/2013 10:26 AM, Yin Kangkai wrote:
On 2013-11-04, 01:00 +0000, MyungJoo Ham wrote:
On sexta-feira, 1 de novembro de 2013 14:25:48, Carsten Haitzler wrote:
e_dbus and eldbus (the e one(s)) use libdbus - so if libdbus ports to
kdbus.. efl will be fine. :)
That's not going to happen. libdbus-1 will not be ported because the codebase
is too hard to work with. One of the major sources of performance problems in
D-Bus is the recursive marshalling code in that library, which was written in
2005 and was never optimised.
libdbus port for kdbus?
https://review.tizen.org/gerrit/gitweb?p=platform/upstream/dbus.git;a=shortlog;h=refs/heads/kdbus-dev
That's what these discussions are talking about, (my understanding)
port libdbus (and make all these changes transparent to libdbus users)
approach is not align with upstream, and leads to a dead end.
But as Carsten and Thiago said in another mails, bridge daemon and
port to kdbus separately for EACH individual libdbus user approach
seems too heavy however.
Can we push back to upstream? (about port libdbus)
i don't think it's heavy to ask to do this... i just think we need to
realize that it won't be a quick port IF we want to remove the presence
of any bridge daemon. it may take a while Or much more advance notice to
plan manpower ahead of time (which equates to a longer timeframe anyway).
--
The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law
including the Unfair Competition Prevention and Trade Secret Protection
Act. Any unauthorized dissemination, distribution, copying or use of the
information contained in this communication is strictly prohibited. If
you have received this communication in error, please notify the sender
by email and delete this communication immediately.
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
