From: Gerd Hoffmann <kraxel@redhat.com>
To: "Marc-André Lureau" <marcandre.lureau@gmail.com>
Cc: spice-devel <spice-devel@lists.freedesktop.org>,
"Alon Levy" <alevy@redhat.com>,
qemu-devel@nongnu.org,
"Marc-André Lureau" <marcandre.lureau@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 0/6] RFC: add "spiceport" chardev
Date: Fri, 30 Nov 2012 16:51:58 +0100 [thread overview]
Message-ID: <50B8D61E.7080808@redhat.com> (raw)
In-Reply-To: <CAJ+F1CKh--i90MWPOi4GY8B5xXSjVuoA8Hu4W_YvbQqt53kDEQ@mail.gmail.com>
Hi,
>> What is the use case? Any reason why the spice client can not (or
>> should not) speak to ovirt directly?
>
> Ah, in fact, it's the main reason why I worked on this. Currently, the
> Spice client has to communicate with ovirt via the browser, which is a pain
> to deal with: it's a completely different route, it needs a running
> browser, a compatible extension (xpi vs activex vs the rest not supported),
> leading to duplicated work, license problems, regular breakage between
> browser versions, hard to test, difficult to upgrade...
Understood.
> Instead, we are
> investigating the use of a configuration file provided by ovirt portal for
> setting up the client, and the dynamic interaction could take place either
> via the propose Spice port, or directly via ovirt.
>
> Some of the dynamic ovirt functionality are interesting for direct clients,
> like the "spice controller menu" (a customizable client UI menu,
> virt-viewer and Boxes could benefit it). It may not be the best solution to
> route the "ovirt/spice controller" through qemu host, but at least I wanted
> to try that option. It could be that in the end, it is prefered that the
> client just talk directly to ovirt, whatever fits best.
I'd go for a direct connection. Going the indirect route via qemu
probably isn't as bad as going indirectly via browser, but still.
Unless there is a very good reason to use qemu as middle man I simply
wouldn't do that.
cheers,
Gerd
prev parent reply other threads:[~2012-11-30 15:52 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-30 13:25 [Qemu-devel] [PATCH 0/6] RFC: add "spiceport" chardev Marc-André Lureau
2012-11-30 13:25 ` [Qemu-devel] [PATCH 1/6] qemu-char: add qemu_chr_remove_clients() Marc-André Lureau
2012-11-30 13:25 ` [Qemu-devel] [PATCH 2/6] spice-qemu-char: write to chardev whatever amount it can read Marc-André Lureau
2012-12-02 10:00 ` Alon Levy
2012-11-30 13:25 ` [Qemu-devel] [PATCH 3/6] spice-qemu-char: factor out CharDriverState creation Marc-André Lureau
2012-11-30 13:25 ` [Qemu-devel] [PATCH 4/6] spice-qemu-char: add spiceport chardev Marc-André Lureau
2012-11-30 13:25 ` [Qemu-devel] [PATCH 5/6] spice-qemu-char: keep a list of spice chardev Marc-André Lureau
2012-11-30 13:25 ` [Qemu-devel] [PATCH 6/6] spice-qemu-char: register spicevmc ports during qemu_spice_init() Marc-André Lureau
2012-11-30 13:58 ` [Qemu-devel] [PATCH 0/6] RFC: add "spiceport" chardev Gerd Hoffmann
2012-11-30 14:42 ` Marc-André Lureau
2012-11-30 15:51 ` Gerd Hoffmann [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50B8D61E.7080808@redhat.com \
--to=kraxel@redhat.com \
--cc=alevy@redhat.com \
--cc=marcandre.lureau@gmail.com \
--cc=marcandre.lureau@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=spice-devel@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.