On Sun, Jun 14, 2009 at 06:50:02PM -0400, Cole Robinson wrote: > git clone http://fedorapeople.org/~crobinso/osinfo/.git I'm not convinced by the "arbitrary hierarchy" thing: I just don't see how that could possibly be useful. Surely it's either an entirely flat namespace, or a shallow structured one like you have. The flat namespace would be a set of keys and multiple values for each key. One value would be "os type" (linux, windows, etc.). You'd most likely have a "generic" entry still for fallback. An alternative is to represent the hierarchy in the UNIX way, via the filesystem: /var/lib/osinfo/ /var/lib/osinfo/linux/info.xml /var/lib/osinfo/linux/fedora/info.xml /var/lib/osinfo/linux/fedora/8/info.xml The fallback is pretty obvious then. Maybe it's over the top. The idea of a single delivered XML file that users edit does trouble me though. Maybe we at least have two files, one for customisations. > int os_init(); > void os_close(); Always, always, always, pass back an opaque identifier in an API - you never know when you'll need to track per-thread state. It's generally a good idea to pass in a version define too. The XML parsing itself should happen lazily. We might want to let the user specify a file, for example. > int os_find_families (char ***list); > int os_find_distros (const char *parent_id, char ***list); > int os_find_releases (const char *parent_id, char ***list); > int os_find_updates (const char *parent_id, char ***list); Regardless of the hierarchy question I hate the idea of exposing it in the API like this. There's really two (hopefully three eventually) things this library needs to do: provide a list of everything it knows about so the user can select it in a GUI or whatever, and provide configuration recommendations given a particular set of values. I don't think the library can make any assumptions about how the former might look. It just needs to return some thing like: struct osinfo { const char *id; nvpair_list_t values; }; Either allocated as an array (probably easiest) or in a list. It's then up to the client to decide what hierarchy to actually use, and it's all dependent on what values they pick out of the nv list. (The third thing is to identify OS types based upon installation media when possible.) > If we do away with the family/distro/... distinction, the user won't have > much choice in the matter, but the 'family' concept (e.g. value of > 'Red Hat') isn't very useful to expose to a user. If you mean API user, think "icon". > - How should we handle derivatives like Scientific Linux + CentOS: should we > expect users to understand they are based on RHEL, or give them explicit > IDs? Explicit IDs. You'd be surprised. > We would need to find the intersection of what the OS, the hypervisor, > and libvirt support, and return what we decide is the best choice. > > How to expose this in the API? We could simply have one long function > > os_lookup_device_value(char *os_id, char *virt_type, char *arch, ...) The API user should pass in an nvlist, where a set of the names are defined and known about. The response needs to indicate whether it's a preferred setting ("would like virtio") or a required one. regards john _______________________________________________ et-mgmt-tools mailing list et-mgmt-tools@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/et-mgmt-tools
