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

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



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


Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|


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