<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 18, 2013 at 1:51 AM, Marc-André Lureau <span dir="ltr"><<a href="mailto:mlureau@redhat.com" target="_blank">mlureau@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
----- Mensaje original -----<br>
> Thanks for the answer, Marc-Andr é !<br>
<div class="im">><br>
> I'll think about these areas of enhancements you've suggested. They need a<br>
> bit of clarification though - because it isn't clear for a newcomer what and<br>
> how to improve :)<br>
><br>
> As for OS preferences, I'm a cross-platform guy, though giving a favor to<br>
> Linux naturally. This may be considered as a minus as I'm used to<br>
> cross-platform frameworks which do so much low-level work and hide<br>
> OS-specifics behind nice interfaces... I want to mention that I'm used to<br>
> C++, so getting in mostly C-written components would be harder for me. What<br>
> Spice parts are more C++-friendly actually?<br>
<br>
</div>Iirc, the browser plugins (only XPI is public atm), and win-vdagent are C++.<br>
<br>
The rest is in C. The Spice client is sharing 99% of the code, while the<br>
platform-specific bits are handled at lower levels: gdk/cairo etc..<br>
The code is quite portable, thanks to libraries like GLib/GIO/Gtk+.<br>
<br>
But there are still platform-specific components that are not portable<br>
(this situation could still be improved).<br>
<div class="im"><br>
> BTW, right now I've come across 2 tickets in the tracker:<br>
</div>> <a href="https://bugs.freedesktop.org/show_bug.cgi?id=63807(" target="_blank">https://bugs.freedesktop.org/show_bug.cgi?id=63807(</a> No way to filter<br>
> devices) and <a href="https://bugs.freedesktop.org/show_bug.cgi?id=62033" target="_blank">https://bugs.freedesktop.org/show_bug.cgi?id=62033</a> ( Means to<br>
<div class="im">> detect local-only, and related<br>
> <a href="https://bugs.freedesktop.org/show_bug.cgi?id=62187" target="_blank">https://bugs.freedesktop.org/show_bug.cgi?id=62187</a> ,<br>
</div>> <a href="https://bugs.freedesktop.org/show_bug.cgi?id=62188" target="_blank">https://bugs.freedesktop.org/show_bug.cgi?id=62188</a> ). Are they relevant to<br>
<div class="im">> work on? I need an advice on how to actually fix them (I've added some<br>
> initial suggestions/questions in comments).<br>
<br>
</div>There is a lot of improvements possible for local-only, and this is very relevant for desktop applications like Boxes. It is not so relevant for VDI in general, so it's not highest priority. It's indeed a good bug to work on.<br>
</blockquote><div><br></div><div>OK, I'm going to start with this one. As I understand, following changes are needed:<br></div><div>1. Add local/remote detection function to server code [based on what? compare own src IP address and dst of the client?]<br>
</div><div>2. Add new interface at vdagent level [How vdagent can/should provide this information to the user? what kind interface should be added? Shared library? Adding it only for this purpose doesn't seem to make sense; but if some other functionality is needed at the guest, it maybe a good way to do this...]<br>
</div><div>3. Add a communication between these new parts [guess it should be done via some virtual device; should this be a request from vdagent to server? Or notification from server?]<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
Regarding USB filtering, the bug was has a solution and was reopened. Imho, this is quite out of scope of Spice client libraries, so it should be handled at a different level, either libusb* or in the application. Probably in the application until a good API is found.<br>

<div class="im"><br></div></blockquote><div><br></div><div>OK...<br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
><br>
> For my future work I'm thinking about particular features useful for<br>
> enhancing VoIP clients performance/quality within VDI. One of them is listed<br>
</div>> at the wiki, <a href="http://spice-space.org/page/Features/CodecPassthrough" target="_blank">http://spice-space.org/page/Features/CodecPassthrough</a> . While<br>
<div class="im">> it is useful(and probably should be done at first, or alongside), I think<br>
> there are even better possibilities - when the traffic doesn't go to VM at<br>
> all. How to implement this - it is another question:) One of the most<br>
> obvious ways is to implement something like 'remote media engine' capability<br>
> for spice client, and provide an API to apps running at guest via extending<br>
> vdagent. It should be easier for audio-only solution, for video-capable<br>
> another level of integration would be needed, when this media engine would<br>
> be rendering video in the app-provided window from the guest... Some sort of<br>
> such 'window overlay' APIs are part of Citrix HDX and VMWare Horizon View<br>
> suites actually.<br>
<br>
</div>Do applications need to be aware of those API? Perhaps we could implement that? Tbh, I think a Linux solution using GStreamer elements should work. But adapting Windows directshow/media/whatever API to use that framework under the hood might be difficult. We lack of Windows experience to tell what is the best level or API to hook into.<br>

<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div>This API makes sense for VDI-only users, when the local system isn't used for anything except remote viewer (e.g. thin client). This is a common use case for enterprise VDI, and probably irrelevant for most non-enterprise users... I don't know what Windows framework would be the best for this task; afaik GStreamer is available for Windows as well. Also there is a cross-platform free/open-source media engine - Google WebRTC, specifically targeting VoIP communications - I think it should be considered too.<br>
<br></div><div><br></div></div>-- <br>Best regards,<br>Fedor
</div></div>