[libvirt] [PATCH 07/10] Introduce generic RPC server objects

[Daniel Veillard]

On Fri, Jun 24, 2011 at 11:35:15AM +0100, Daniel P. Berrange wrote:
> On Fri, Jun 24, 2011 at 01:08:47PM +0800, Daniel Veillard wrote:
> > On Wed, Jun 22, 2011 at 04:33:56PM +0100, Daniel P. Berrange wrote:
> > > To facilitate creation of new daemons providing XDR RPC services,
> > > pull alot of the libvirtd daemon code into a set of reusable
> > > objects.
> > > 
> > >  * virNetServer: A server contains one or more services which
> > >    accept incoming clients. It maintains the list of active
> > >    clients. It has a list of RPC programs which can be used
> > >    by clients. When clients produce a complete RPC message,
> > >    the server passes this onto the corresponding program for
> > >    handling, and queues any response back with the client.
> > > 
> > >  * virNetServerClient: Encapsulates a single client connection.
> > >    All I/O for the client is handled, reading & writing RPC
> > >    messages.
> > > 
> > >  * virNetServerProgram: Handles processing and dispatch of
> > >    RPC method calls for a single RPC (program,version).
> > >    Multiple programs can be registered with the server.
> > > 
> > >  * virNetServerService: Encapsulates socket(s) listening for
> > >    new connections. Each service listens on a single host/port,
> > >    but may have multiple sockets if on a dual IPv4/6 host.
> > > 
> > > Each new daemon now merely has to define the list of RPC procedures
> > > & their handlers. It does not need to deal with any network related
> > > functionality at all.
> > 
> >   I very much like this, this is a significant chunk of code though.
> > And well libvirtd won't be using it with the current patch set (well
> > unless I missed it), I would expect a patch trimming the daemon
> > directory and making it use those new pieces of code, unless I missed
> > something. The "advantage" is that we would have immediate testing of
> > that code, the disadvantage being that the libvirtd may get new bugs
> > from the reimplementation.
> > 
> >   Did I miss something or is the current choice of not using the
> > new APIs for libvird a trade-off ?
> 
> I still have the patches to actually convert the remote driver and
> libvirtd and I will post them when I have merged all this and done
> some more testing. I've rebased them soooooo many times I need to
> run a complete set of tests again to make sure I didn't break any
> code

  Okay, let's push the first set and then we will see next week if
we take the risk to switch the daemon and remote driver to those new
APIs (IMHO I would go for it because otherwise it will be hard to
really get testing...)

Daniel

-- 
Daniel Veillard      | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
daniel at veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/