On Thu, Feb 01, 2007 at 05:02:08PM +0000, Mark McLoughlin wrote: > On Wed, 2007-01-31 at 15:25 +0000, Richard W.M. Jones wrote: > > > * Remote URLs contain either a server name or a remote transport > > * name. For example: "qemud://server.example.com/system" contains > > * a server name (server.example.com), and "qemud+unix:///system" > > * contains a transport (unix). Commonly remote URLs contain > > * both, for example: "qemud+tls://server.example.com/system" > > * (transport tls, server name server.example.com). > > This makes my head hurt a bit, I think I prefer the libvirt:// even if > it means encoding URIs in URIs. > > i.e. I would expect to connect to e.g. qemud:// and xend:// URIs to > using the same protocol whether the URI is local or remote. That's already not the case with Xen. I think of the leading foo:// bit of the URI to mean the type of libvirt driver being requested. For xen this can be hypercalls, xend or libvirt_proxy. We now merely adding in libvirtd for delaing with case of asking for a remote connection. Not to mention that we reserve the right to change the underlying comms protocol associated with a URI. eg changing from xend SEXPR to xend's XML-RPC/ > I don't know, it's not something I really care about ... but I'd find > it strange if qemud+tls://foo.bar.com/system means "access > qemud:///system via a libvirt proxy" ... I all really comes down to what we want to define the URIs to mean in the context of libvirt. With my virt-manager hat on, it makes life much nicer to have qemud:///system and qemud://example.com/system when dealing with URIs internally. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|