[Spice-devel] Looking for help to start learning Spice through bugfix/design

[Fedor Lyakhov]

On Tue, Jun 18, 2013 at 1:51 AM, Marc-André Lureau <mlureau at redhat.com>wrote:

>
>
> ----- Mensaje original -----
> > Thanks for the answer, Marc-Andr é !
> >
> > I'll think about these areas of enhancements you've suggested. They need
> a
> > bit of clarification though - because it isn't clear for a newcomer what
> and
> > how to improve :)
> >
> > As for OS preferences, I'm a cross-platform guy, though giving a favor to
> > Linux naturally. This may be considered as a minus as I'm used to
> > cross-platform frameworks which do so much low-level work and hide
> > OS-specifics behind nice interfaces... I want to mention that I'm used to
> > C++, so getting in mostly C-written components would be harder for me.
> What
> > Spice parts are more C++-friendly actually?
>
> Iirc, the browser plugins (only XPI is public atm), and win-vdagent are
> C++.
>
> The rest is in C. The Spice client is sharing 99% of the code, while the
> platform-specific bits are handled at lower levels: gdk/cairo etc..
> The code is quite portable, thanks to libraries like GLib/GIO/Gtk+.
>
> But there are still platform-specific components that are not portable
> (this situation could still be improved).
>
> > BTW, right now I've come across 2 tickets in the tracker:
> > https://bugs.freedesktop.org/show_bug.cgi?id=63807( No way to filter
> > devices) and https://bugs.freedesktop.org/show_bug.cgi?id=62033 ( Means
> to
> > detect local-only, and related
> > https://bugs.freedesktop.org/show_bug.cgi?id=62187 ,
> > https://bugs.freedesktop.org/show_bug.cgi?id=62188 ). Are they relevant
> to
> > work on? I need an advice on how to actually fix them (I've added some
> > initial suggestions/questions in comments).
>
> 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.
>

OK, I'm going to start with this one. As I understand, following changes
are needed:
1. Add local/remote detection function to server code [based on what?
compare own src IP address and dst of the client?]
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...]
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?]


>
> 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.
>
>
OK...



> >
> > For my future work I'm thinking about particular features useful for
> > enhancing VoIP clients performance/quality within VDI. One of them is
> listed
> > at the wiki, http://spice-space.org/page/Features/CodecPassthrough .
> While
> > it is useful(and probably should be done at first, or alongside), I think
> > there are even better possibilities - when the traffic doesn't go to VM
> at
> > all. How to implement this - it is another question:) One of the most
> > obvious ways is to implement something like 'remote media engine'
> capability
> > for spice client, and provide an API to apps running at guest via
> extending
> > vdagent. It should be easier for audio-only solution, for video-capable
> > another level of integration would be needed, when this media engine
> would
> > be rendering video in the app-provided window from the guest... Some
> sort of
> > such 'window overlay' APIs are part of Citrix HDX and VMWare Horizon View
> > suites actually.
>
> 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.
>
> 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.


-- 
Best regards,
Fedor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/spice-devel/attachments/20130619/1eb17994/attachment.html>