On Thu, 2009-08-20 at 18:20 +0100, Patrick Ohly wrote:
> But the biggest drawback is that the implementation of the wrappers is
> based on templates which depend on the number of parameters to be
> wrapped. This implies that code must be copied and adapted to cover a
> wide range of parameter numbers. This would be avoided by a code
> generator.
>
> What do you think? Is this worthwhile pursuing further?
You still have a chance to stop me... please comment if you think that
this advanced usage of C++ is becoming to complicated.
As Jussi was okay with the general direction, I investigated a bit
further and made some more improvements:
* support signals and easy object registration (DBusObject,
DBusObjectHelpter, EmitSignal)
* added notification mechanism for peers which disconnect while a
server processes their method call asynchronously
(Result::createWatch)
* several fixes in gdbus
Apparently some of things that I was doing (registering and
unregistering watches and objects repeatedly, multiple interfaces per
object) have not been done before with the gdbus code and didn't work
(including segfaults due to incorrect memory handling).
g_dbus_create_error() ignored the detailed error description.
I have patches for all of this, which I will send upstream once this is
all more complete and better tested. Perhaps there'll be more changes.
Marcel, what's the best place to coordinate development of gdbus?
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
