[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[virt-tools-list] Re: libosinfo - another try



On Thu, Oct 22, 2009 at 05:47:04AM -0400, Arjun Roy wrote:
> 1. All the data stored right now as a python dict would be replaced with a
> collection of xml (or any other kind of markup that works) file encoding the
> same data.

It is fairly important that this data store be user updatable, without
negatively impacting RPM upgrades. So should not be one single giant
file, but rather lots of individual files so users can easily add in
data 

> The primary storage record would be the <distro>. It would consist of a required
> ID, and one or more optional attributes.

I think an integer ID is a bad idea because it makes custom local updates hard
to resolve wrt later updates without risk of clashing keys. I think it would
be better to use RDF  here, linking using URIs

> There would be two kinds of attributes:
> 
> 1. Structure Attributes
> 
> These attributes would encode possible relationships between distros. Proposed
> attributes would be:
> <derives-from>
> <clones>
> <upgrades>
> 
> So one could have the following:
> <distro ID=1>
>   <name>Fedora 10</name>
> </distro>
> 
> <distro ID=2>
>   <name>Fedora 11</name>
>   <upgrades ID=1 />
> </distro>

If we used RDF this would allow for

  <distro rdf:about="http://fedoraproject.org/fedora-10";>
   <name>Fedora 10</name>
  </distro>

  <distro rdf:about="http://fedoraproject.org/fedora-11";>
    <name>Fedora 11</name>
    <upgrades rdf:resource="http://fedoraproject.org/fedora-10"/>
  </distro>


NB, RDF  URIs don't have to actually point to any real webpage, they
are just a unique namespace

> 2. Informative Attributes
> This could refer to things such as name, kernel-type, architecture, or anything
> else that would be useful to track. I suspect that it would be alright to limit
> the kind of data to strings (kernel : linux) and version numbers 
> (kernel-version: 2.6.30).
> 
> In other words, we'd end up with a schema like this:
> <distro ID=2>
>   <upgrades ID=1 />
>   <name type=str>Fedora 11</name>
>   <kernel type=str>linux</kernel>
>   <kernel-version type=ver>2.6.30</kernel-version>
> </distro>

I don't think this type=str vs type=ver is really adding anything of
value here. You can't rely on projects providing nicely parsable
version numbers, so in practice you just end up with version strings
instead.

> The library would be implemented in C, and define a few major types:
> 
> osi_lib_t : an opaque handle to a library instance.
> osi_distro_t : represents a distro object.
> osi_distro_id_t : represents the unique ID for a distro.
> osi_distro_list_t : a list of osi_distro_t objects.
> osi_filter_t: filter for searching through distros.
> 
> And a bunch of methods:
> 
> osi_lib_t osi_getLibHandle();

Either CamelCase or underscores, but please not a mix of both :-(

> /* Setting parameters like libvirt version, etc. */
> int osi_setLibParam(osi_lib_t lib, cstring key, cstring val);
> int osi_getLibParam(osi_lib_t lib, cstring key);

Unless there's a really compelling reason not to, it is better to use
standard   'char *' or 'const char *' for strings - it makes life much
nicer for people writing bindings to other languages.

> 
> /* Initializing and closing down the library */
> int osi_initLib(osi_lib_t lib);
> int osi_closeLib(osi_lib_t lib);
> 
> /* Querying for distros and iterating over them */
> osi_distro_list_t osi_getDistrosList(osi_lib_t lib, osi_distro_filter_t filter);
> int osi_putDistrosList(osi_distro_list_t distros);
> int osi_distroListLength(osi_distro_list_t distros);

What does the 'Put'  method do ?

> 
> /* Methods for filtering results when querying distros */
> osi_filter_t osi_getFilter(osi_lib_t lib);
> int osi_putFilter(osi_filter_t filter);
> int osi_addStringPropertyConstraint(osi_filter_t filter, cstring propName, cstring propVal);
> int osi_addVersionPropertyConstraint(osi_filter_t filter, cstring propName, cstring propVal, enum_t ordering);
> int osi_addLinkedDistroConstraint(osi_filter_t filter, enum_t relationship, os_distro_t distro);
> int osi_clearStringPropertyConstraint(osi_filter_t filter, cstring propName);
> int osi_clearVersionPropertyConstraint(osi_filter_t filter, cstring propName);
> int osi_clearLinkedDistroConstraint(osi_filter_t filter, enum_t relationship);
> int osi_clearAllConstraints(osi_filter_t filter);

Again I don't think the String/Version  distinction is really helping
here. I think we should just use strings for all properties.


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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]