WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] A migration framework for external devices

To: "Mike D. Day" <ncmike@xxxxxxxxxx>
Subject: Re: [Xen-devel] A migration framework for external devices
From: Daniel Veillard <veillard@xxxxxxxxxx>
Date: Thu, 9 Feb 2006 10:01:27 -0500
Cc: "Cihula, Joseph" <joseph.cihula@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Stefan Berger <stefanb@xxxxxxxxxx>, "Scarlata, Vincent R" <vincent.r.scarlata@xxxxxxxxx>, Ronald Perez <ronpz@xxxxxxxxxx>
Delivery-date: Thu, 09 Feb 2006 15:12:44 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <43EB36DB.7080302@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <OFAF40C2ED.9A049C9A-ON8525710F.007C18EC-8525710F.007C8530@xxxxxxxxxx> <43EB36DB.7080302@xxxxxxxxxx>
Reply-to: veillard@xxxxxxxxxx
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.4.1i
On Thu, Feb 09, 2006 at 07:34:35AM -0500, Mike D. Day wrote:
> adds event and procedural semantics. xml encodings are already defined 
> for everything we need including bulk data transfers, event semantics, 
> and remote procedure calls. However, I don't think we should use xml 
> encodings for bulk data transfer. We could keep that part as it is now.

  XML for transporting random data is a really bad fit, you need basically
to encode it with base64 (or else), it becomes bulky, loose the stucture
aspects of XML, and gets really inefficient. 
  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).
  So how do you plan to glue the XML and the other parts together ?

Daniel

-- 
Daniel Veillard      | Red Hat http://redhat.com/
veillard@xxxxxxxxxx  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel