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