On Fri, Apr 01, 2011 at 05:29:15PM +0200, Michal Privoznik wrote:
> ---
> include/libvirt/libvirt.h.in | 7 +++++++
> src/libvirt_public.syms | 1 +
> 2 files changed, 8 insertions(+), 0 deletions(-)
>
> diff --git a/include/libvirt/libvirt.h.in b/include/libvirt/libvirt.h.in
> index bd36015..42711e6 100644
> --- a/include/libvirt/libvirt.h.in
> +++ b/include/libvirt/libvirt.h.in
> @@ -670,6 +670,13 @@ int virDomainCoreDump (virDomainPtr domain,
> int flags);
>
> /*
> + * Screenshot of current domain console
> + */
> +int virDomainScreenshot (virDomainPtr domain,
> + const char *to,
> + int flags);
I'm loathe to introduce any new APIs which accept a filename
argument, because they're essentially useless for any app
talking to libvirtd remotely, and often troublesome for
non-privileged apps talking to privileged libvirtd.
I think this API should instead use the virStreamPtr facility,
making it follow the design of the virStorageVolDownload()
API I recently added.
A minor point is that 'flags' should be 'unsigned int'
The question of file format is another interesting issue.
We might want to actually return a string representing the
mime-type of the output file.
eg,
char * virDomainScreenshot (virDomainPtr domain,
virStreamPtr stream,
unsigned int flags);
char *mimetype = virDomainScreenshot(dom, st, 0);
So then the client app can decide what file extension to use when saving
the data, or when parsing it in memory.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list