On 11/04/2013 02: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)
Yes, of course. Trees that were pushed to tizen.org are there to make development a bit more transparent. We plan to squash all of kdbus-dev history into few commits with clearly separated functionality and send that as RFC to respective mailing lists. We (me and Lukasz) would prepare glib, while I would like ask Jacek to do similar thing with libdbus. Jacek, are you ok with that? Cheers, Karol _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
