[libvirt] [PATCH] storage pool discovery

Daniel P. Berrange berrange at redhat.com
Wed Aug 27 16:51:56 UTC 2008


On Mon, Aug 25, 2008 at 10:33:45AM -0400, David Lively wrote:
> On Fri, 2008-08-22 at 16:15 +0100, Daniel P. Berrange wrote:
> > On Fri, Aug 22, 2008 at 10:58:54AM -0400, David Lively wrote:
> > > As long as we're on the subject of naming (and before it's too late),
> > > it's been bothering me that we keep calling this "storage pool
> > > discovery".  To me, "storage source discovery" seems more accurate
> > > (because they're not pools until we define libvirt pools based on the
> > > sources).  So I'd prefer renaming the various *Discover[Storage]Pools*
> > > functions (and support structs) introduced in this patch to
> > > *Discover[Storage]Sources*.  I was just sticking with the
> > > originally-proposed names to avoid confusion.  What do you all think?
> > 
> > That sounds like a reasonable idea to me.
> 
> [Sorry to harp on the naming issue.  But names are important, and we
> can't change them once they're in the API ...]
> 
> After making the change I suggested above, it now feels a little strange
> because "Pool" is gone from the name.  I'm starting to think
> "*Discover[Storage]PoolSources*" is the only good choice.  It's rather
> long, but makes it clear we're talking about storage pool sources (as
> opposed to "storage sources", which feels a little ambiguous, or
> "storage pools" which isn't accurate since they're not (yet) pools).

Discover is a bit of a long word - lets use 'Find' instead, so it makes
the API name a little shorter - and no worse than our existing longest
API name. In other words:

   virConnectFindStoragePoolSources()

Regards,
Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|




More information about the libvir-list mailing list