On 03/13/2014 03:44 PM, Dmitri Pal wrote:
On 03/13/2014 10:33 AM, Jakub Hrozek wrote:
On Thu, Mar 13, 2014 at 03:24:22PM +0100, Pavel Březina wrote:
On 03/10/2014 06:14 PM, Sumit Bose wrote:
On Fri, Mar 07, 2014 at 03:02:30PM +0100, Jakub Hrozek wrote:
Fair enough. I saw both complaints from potential consumers -- some
developers were going "omg dbus is such a heavyweight desktop
technology,
do I really need to use it" ? I realize 'hiding' dbus behind a
different
name might be a little irrational, but so were their concerns in my
opinion.
I think as long as well call it the D-Bus responder we should keep dbus
in the names. Otherwise we might get questions like 'How do I start the
InfoPipe responder?'.
It is actually already confusing. We never use anything else than
D-Bus responder, but the responder itself in Jakub's branch is
called ifp.
That's because the original DBus responder from cca 2008 was called
InfoPipe, I simply reused the original name.
Are you proposing to call the responder simply dbus?
I think we can just start using the work "infopipe" again.
https://fedorahosted.org/sssd/wiki/DesignDocs/DBusSimpleAPI
I have made several changes to support more type of properties than just
a string. In addition to these:
* struct sss_dbus_attr was made opaque
* added type for string:string dictionary
* added sss_dbus_send_message() to get message for IFP bus
* renamed D-Bus responder to InfoPipe responder (I left the prefix
sss_dbus though, because the D-Bus behind is not completely opaque)
I have made many of these changes as needed on the fly. I have the code
ready and I have unit test for message parsing functionality. I yet have
to write some test for the public interface, after that I'll send the
new code.
_______________________________________________
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
