From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Veillard Subject: Re: A migration framework for external devices Date: Mon, 13 Feb 2006 05:18:39 -0500 Message-ID: <20060213101839.GF9506@redhat.com> References: <43EB36DB.7080302@us.ibm.com> <20060209150127.GQ30975@redhat.com> <43EB6969.6020007@us.ibm.com> Reply-To: veillard@redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <43EB6969.6020007@us.ibm.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Mike D. Day" Cc: "Cihula, Joseph" , xen-devel@lists.xensource.com, Stefan Berger , "Scarlata, Vincent R" , Ronald Perez List-Id: xen-devel@lists.xenproject.org On Thu, Feb 09, 2006 at 11:10:17AM -0500, Mike D. Day wrote: > Daniel Veillard wrote: > > So how do you plan to glue the XML and the other parts together ? > > One way is to have two channels (like ftp). Have an xml session channel Urgh, way more complex, you start hitting synchronization problems requiring more round trips etc ... Maybe the convenience still makes sense though. > and a tcp data channel. That gives the benefits of xml-rpc for > triggering events and invoking plugins. You could use xml-rpc to > negotiate the port for the migration data transfer, for example. Then > use the data channel (scp/tcp) for the migration. > > I'm not convinced this approach is better than starting from scratch tho. I can't tell :-) I was just raising a problem which could happen in the proposal, I still have much to read/learn on the current state... Daniel -- Daniel Veillard | Red Hat http://redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/