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
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
