Re: [Libvir] [RFC] Life-cycle Management of the domain take2

On Fri, Apr 27, 2007 at 07:57:09PM +0900, Saori Fukuta wrote: I dislike the fact that we are making API confusing. At the beginning, it was simple, a domain is a running instance, and API works on domain. Then we started adding support for defined domains, with the premice that a domain was either active or inactive, so the change in API semantic was minimal. Now you are proposing to override this with another layer of APIs which allow a domain to be both the definition file somewhere, or the running instance, or both or something next ... I'm saying, stop ! To me we are trying to push patches without keeping the coehrency of the definitions http://libvirt.org/intro.html "a domain is an instance of an operating system running on a virtualized machine provided by the hypervisor" Maybe we need a different definition for what is a domain description, and then we can add APIs for those, but the confusion generated by the drift of what a Domain may represent, starts now to impact the API and I don't want that ! The goal is to keep the API simple, when you start having APIs where an extra argument is added to change the primary signification of what one of the argument means: - that means you have lost track of the objects exposed by the API - the API is becoming confusing Now I understand you want a way to modify the Domain descriptions. This should *NOT* use the virDomainPtr as the argument in the API. You need to define a different type of object, not overload the semantic of similar API. Define APIs with a different object virDomainDescription which could be loaded from a file, a descriptor or memory, or grabbed from a running virDomain then defines similar API to modify them if needed. But the fact that you can't get some informations like the VNC port number from a running domain, while you could get it from a description file is no excuse to start multiplying APIs. You're just trying to use the wrong object for the job. I don't think the current patches you provided are in the right direction, I'm sorry I didn't manage to express my concern before more clearly but now I think I know why I was resistant to your earlier suggestions. You are trying to add functionalities in libvirt for object we don't have a good representation for (descriptions of domains). But even if we want to do similar kind of operation on those objects they are fundamentally of a different type. And to address this cleanly we need to add support for those type instead. This certainly deserve some discussions about how to define domain description types what kind of methods they would take, but the more I think about it the cleaner and easier it will be if we take that path instead. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/