[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: netconf control socket protocol: rfc822, xml-rpc, or dbus




"Pierre Habouzit" <madcoder@artemis.madism.org> wrote in message [🔎] 20080108165521.GB4783@artemis.madism.org">news:[🔎] 20080108165521.GB4783@artemis.madism.org...
 That's wrong, and XML-RPC *SUCKS*, as does most of the text-only
interfaces, when you want real-time events. DBus isn't such a bad way to
do things, it doesn't requires the daemon up and running to interact
with netconf, when netconf acts as a dbus server.

Huh? If by "the daemon" you are refering to the netconf daemon, and if by dbus server you meant D-Bus service (an app the dbus daemon can launch on demand) then that matches my reading. But if "the daemon" meant the D-Bus daemon, and you did mean dbus server, then that does not match my understanding. From my reading of the docs, I thought that the dbus daemon must be running
for the protocol to work at all.

I assume that it's
possible to write tools that directly hit your netconf server withouth
going through the dbus daemon, making it lightweight and a really good
solution even for small systems.

That is how it currently works. The idea is to have two packages, one that is the actual service with some kind of protocol working over a control socket. A second package would provide a DBus interface, and basically translate DBus messages to whatever the native message format of the control pipe is.

However, he would still need some sort of protocol for the control socket.

The alternative is to have the control socket use the D-Bus system, meaning only one package is needed, but messages
would need to pass through the dbus-daemon in order to be recieved.


 And then for 0 cost, you see desktops being able to use your
procedures being routed automatically through the dbus daemon acting as a
proxy. At least it's what I grok reading [0]. And that's an invaluable
advantage as almost all desktop applications are slowly (or not _that_
slowly actually) migrating to DBus. It means that you'll provide a
tested robust known interface to people wanting to interface with you.

That is very true. A dersktop network managment tool could certainly send messages to netconf with ease using
D-Bus, which is a really nice feature.




Reply to: