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 :| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list