Re: [Libguestfs] [PATCH 1/2] availability: Add guestfs_available.

On 20/11/09 15:12, Richard W.M. Jones wrote: We've been over much of this on IRC, but I think this is the wrong API. Depending on how you choose to manage groups, there are 2 possible reasons why this is the wrong API: 1. Groups remain static ----------------------- In the static group management policy an API group remains constant forever. New APIs are either omitted or added to a new group. This policy has the advantage of having a well-defined meaning. i.e. you can look at the documentation and be sure that if guestfs_available("augeas") returns true then a certain set of augeas APIs are definitely implemented. The problem with this policy is that the groups become unmanageable as new APIs are added. So in a year's time I want to required the full range of augeas apis. I have to remember to check 'augeas', 'augeas_new', 'augeas_newer' and 'augeas_newer_still'. What's more, the mapping to these things is arbitrary because the base has a huge wadge of stuff in it, whereas the incrementals are very small and I can't remember what falls in which bucket. Unless I use this API day in, day out, I will need to head over to the documentation every time to look up the group mappings I need. We end up with a proliferation of unmemorable groups. On the other hand, if we changed the API to instead test individual APIs, the mappings would be both obvious and managable. This is the wrong model because it will be unusable soon after release. 2. Groups are updated to include new APIs ----------------------------------------- In this model, a new augeas call would be added to the augeas group. This policy can no longer be called 'availability' because it does not determine the availability of an API. For example, augeas_new is introduced in libguestfs version X, and the augeas group is updated. The problem now is that if the code is run agains libguestfs version X-1, the test for 'augeas' returns true, despite the fact that my API is not available. For completeness, we also discussed the possibility of versioning groups. We discounted this on the basis that version numbers have little meaning in the face of backports. As I see it, there is no group policy which would make this API usable, except dropping the concept of groups entirely and testing APIs directly. To avoid me having to expound 2 independent arguments, if you can clarify which group management policy you favour, I will gladly expand further on why it is a bad idea. In case it's not obvious, I wouldn't have approved this API ;) Matt -- Matthew Booth, RHCA, RHCSS Red Hat Engineering, Virtualisation Team M: +44 (0)7977 267231 GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490