On Sat, Mar 11, 2006 at 07:44:20PM -0600, Anthony Liguori wrote:
> Ewan Mellor wrote:
> >Anthony, I've reviewed your XML-RPC patches. It all looks good, so I'm in
> >favour of putting them in straight away.
> Thanks!
> >I'd like to get the second patch in
> >straight away as well as the first, that is (for those watching at home) to
> >change xm to using XML-RPC, because I would like to deprecate the old
> >protocol sooner, rather than later. Making the XML-RPC interface the
> >primary
> >control path for Xen 3.0.2 will encourage third-parties to code to that
> >rather
> >than to the s-expression protocol, and that's a good thing.
> >
> Okay. So I'm going to take this to mean that we would deprecate
> S-Expression/HTTP for 3.0.2 and remove it in 3.0.3? That would be
> really nice.
Yes, I hope so. That's assuming that a) no-one objects and b) we get the
config file formats (both the main Xend config file and the xm create config
file) into XML too. I don't see any point removing the s-expression protocol
support unless we can remove the s-expression parser/generator too, but I
certainly think that we should deprecate it for 3.0.2.
> > How about if we prefixed
> >every function that we wish to expose to the messaging layer with
> >"public_"? So for example XendDomainInfo.send_sysrq would be named
> >public_send_sysrq instead. Then, we could use that to guide the
> >function registration, rather than having exclude lists and inline lists
> >of callable methods.
> >
> Isn't using an underscore a convention for making methods private in
> Python? I think, at least, pydoc ignores functions that start with an
> underscore.
A preceding underscore indicates that "from Module import *" should not import
the function, i.e. it's a weak "private" declaration. There's nothing special
about embedded underscores though.
I chose public_get_name over publicGetName because I thought that, at the
XML-RPC level, it would be conventional to have "xend.domain.get_name" as the
message name, rather than "xend.domain.GetName". That's personal taste
though, I don't have a strong opinion here.
> >>
> >> def xend_node_get_dmesg(self):
> >>- return self.xendGet(self.nodeurl('dmesg'))
> >>+ return self.srv.xend.node.dmesg.info()
> >>
> >
> >What you've done here is slipped the new XML-RPC layer under the existing
> >XendClient API. I don't think that we need to support that API at all.
> >All
> >the functions here just turn into stubs onto ServerProxy, and I don't think
> >that those stubs buy us anything.
> >
> Nope. Just compatibility. I know there are people using the XendClient
> API.
There are? Who? Anyone who's using the XendClient API, please speak up!
> >The reason I noticed is that I have been trying to make it so that
> >XendDomain and XendDomainInfo only receive arguments of the correct type,
> >with the casts to integers etc handled by the messaging layer. This
> >change you've made highlights the fact that there is now nowhere for
> >that type conversion to take place, because the messaging layer is more
> >generic, and doesn't understand the calls that it is dispatching.
> >That's OK -- it's a consequence of the removal of all that code in
> >SrvDomain -- but it's something to be aware of. If we adopt the naming
> >convention that I suggest above, then all methods accept only arguments
> >of the correct type _except_ for those named "public_xyz" -- those
> >methods must validate and convert their arguments appropriately.
> >
> Why? If a public_ function expects a domid and gets passed a string, it
> ought to throw an exception and the client should get it as an error.
I don't think that there's any user-facing call which should only accept a
domid -- they should all accept either a domain ID or a domain name. Of
course, xm cannot tell whether it is passing a domain ID or a domain name
(because names may be strings of digits too, and these are typed at the
command line) so I think that any public function must be able to cope with
either case.
That said, if there is some call that accepts only an integer, yes, it ought
to be able to throw an exception. (I think, actually, that we're talking at
cross purposes, and obliquely agreeing with each other).
Cheers,
Ewan.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home