On 04/02/2014 03:34 AM, Michal Privoznik wrote:
If we'd come up with a struct to interpret the time, it's
written
in stone and there's nothing we can do about it. Even if we break
up the struct into function arguments. However, we can use typed
parameters and have the API extensible. For example, I'm
implementing seconds granularity only for now. If later somebody
feels like he/she wants to use even finer granularity, we can do
that by inventing a new typed param. Same goes for timezone, etc.
But what more is there to add besides seconds and nanoseconds (struct
timespec)? We don't have to support full resolution of nanoseconds, and
could either document that we round (possibly to as course as seconds)
or reject input with non-zero nanoseconds if we don't want to support
sub-seconds right away. It just feels awkward to me to have to bundle
something into a virTypedParam when the most we could ever extend this
to is struct timespec, so representing struct timespec via split
parameters from the get-go requires less thought when using the interface.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org