From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Mike D. Day" Subject: Re: A migration framework for external devices Date: Thu, 09 Feb 2006 11:10:17 -0500 Message-ID: <43EB6969.6020007@us.ibm.com> References: <43EB36DB.7080302@us.ibm.com> <20060209150127.GQ30975@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20060209150127.GQ30975@redhat.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: veillard@redhat.com Cc: "Cihula, Joseph" , xen-devel@lists.xensource.com, Stefan Berger , "Scarlata, Vincent R" , Ronald Perez List-Id: xen-devel@lists.xenproject.org Daniel Veillard wrote: > Another common XML related design error is to embbed XML along with > other data in a stream without markers, you end up having to precompute > the size of the XML instance which makes streaming impossible or force > some unclean processing at the XML level (as an XML instance has no end > marker in itself, the end must be provided by the container or the code > driving the parser). Yes, totally agree > 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 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. Mike -- LTC Open Hypervisor Project: 1) Ensure linux has a good GPL hypervisor 2) Ensure Xen exploits xSeries Platforms 3) Provide value-add Xen Extensions for IBM customers.