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:
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