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

[Arjun Roy]

More responses, inline.

On 10/22/2009 10:52 AM, Daniel P. Berrange wrote:
> 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 
That was what I was meant to write. I typo'd it in the original email :)

> 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
>
> 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
>
This would solve the uniqueness problem, but Cole brought up a good point
earlier - if there was a CLI app where users needed to type in some sort of
identifier for a distro, this would be somewhat cumbersome.

Though then again a CLI app could have them just need to type in a part of the
name and pattern match against the full URI?


>> 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.
>
In which case the problem turns into one of; how do we handle these version
strings? Do we just provide them as is, or find some way to compare them? Or is
comparison best left to the user of the API? (That would simplify things for us
considerably)

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

I'll update it in an RFC v2 email shortly.

> 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.
Fair enough. I just wanted to avoid looking at char*** a few methods down, but
I'll change it.

>> /* 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 ?
>
The idea for this library is that all types are opaque, and thus any dynamically
allocated memory has to be handled by the library. So if we got a list of distros
for some query, (or any other object in this API with a related put method) and
now we're done with it, we call 'put' to free the memory.

I suppose 'free' would be more clear.

>>
>> /* 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.
That was my original thought before I entered the version number conundrum. I
think the biggest thorn in our collective sides at present is determining how to
deal with it. (ie. if we farm it out to the user of the api to deal with it, how
much expressiveness do we lose with the library?)

I agree that my current handling of it is a tad ugly.

-Arjun