4:24 p.m.
Hi Tomasz,
On 11/17/2014 04:34 AM, Tomasz Bursztyka wrote:
Hi Denis,
>> There is already a dbus service API in ell. I wanted to keep it,
>> wrapping the
>> gdbus-like API within the existing functions. However that has proven
>> to be
>> impossible unless I would modify the existing API. Thus my
>> conclusion: if I
>> have to break the existing API, let's do it all. So I finnally got
>> rid of the
>> existing API.
>
> I find table/macro based approach unreadable and that is why I did not
> use the gdbus approach in ell. I'm actually quite happy with the
> current API, it fits in with ell's design philosophy much better. If
> someone wants to re-use the API from gdbus I'm good with that, but
> please don't throw stuff out in the process.
>
> Right now we are only focused on iwd, and this is our opportunity to
> try new things. I wouldn't rush to try and replicate old ways of
> doing things.
I am fine with trying new things as long as we identify problems to get
fixed in the old way of doing things.
Readability is pretty subjective, I did not consider it. (I am ok with
the table/macro approach)
To me API readability is the most important aspect. The function based
approach also allows way more flexibility. For example, in GDBUS today,
if we want to implement the non-ObjectManager based APIs, we have omit
the Property definitions (and thus introspection data).
The good part with tables over function calls is that it does all at
once.
Does what all at once? You keep a bunch of static memory around until
someone calls register_interface.
Technically also, it uses less memory, does way less function calls,
probably less context switches etc...
Memory? Maybe, or maybe not. The metadata is pretty compact, what
wastes most is the linked list overhead. But then we are able to play
some pretty neat tricks in order to optimize the introspection
generation and call dispatch.
However, I digress. This is all a drop in the bucket in the context of
the larger program execution. Trying to optimize any of this, while
interesting, is not that productive.
That's also why I kept most of underlying implementation, since
it
technically brings some nice stuff.
The other motivation was of course moving from gdbus to ell in existing
projects could be much harder if the API is that different.
Except you decided to diverge from GDBUS APIs as well for some reason by
introducing L_DBUS_RW_PROPERTY, L_DBUS_RO_PROPERTY, etc ;)
So here's what I propose. If you are dead set on adding
DBus.Properties, then lets do this on top of the existing code. The
GDBUS compatibility layer can be bolted on top of that easily enough.
At the end of the day it is just some extra struct definitions and an
alternative call to l_dbus_register_interface. Can probably be done in
less than a day.
For adding DBus.Properties handlers, we can add something like:
l_dbus_interface_property_add_handlers(interface, property, get_func,
set_func, exists_func);
The first time the above is called, we automagically add DBus.Properties
Interface introspection and capability to the object in question. If it
isn't called, then we don't include DBus.Properties at all.
Regards,
-Denis