Hi Daniel I'm sorry I might be disrespectful a little... I understood descriptions of domains, and I will think over again with members of my team. I appreciate your explaining. thanks a lot ! Saori On Fri, 27 Apr 2007 07:47:51 -0400 Daniel Veillard 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@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ > http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/