On Mon, Jun 15, 2009 at 07:16:56AM -0400, John Levon wrote: > 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. I think this is the way to go. Flat list + properties, and allow apps to build hiearchies on the fly as needed, based off properties. > 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. A single XML file would be pretty horrible for package upgrades. With a flat list we can have 1 XML file per distro. If we allow multiple search paths for XML files, we can have the stadnard shipped ones in /usr/share/osinfo, and customized ones in /etc/osinfo the latter overriding (or inheriting from) the former. > > - 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. Download/install URLs already require that we do separate IDs :-) 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 :| _______________________________________________ et-mgmt-tools mailing list et-mgmt-tools@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/et-mgmt-tools
