[Spice-devel] Full featured (qxl compatible) spice web client released

[jose at eyeos.com]

> Wow! That is astonishing, and well done, congratulations. 
> 
> I've played with it a bit; I had some issues with keyboard problems, and
> it wasn't immediately obvious how to use passwords or ssl. Of course, I
> suspect those are issues that are relatively easy to address.

Keyboard support is one of the most advanced and developed part of the
spice web client. By default it is using spanish keyboard, maybe this is
the reason you experienced keyboard issues? 

In fact, we have used this in production (in spain) with no keyboard
problems at all, even with special characters, but as i said, always
with spanish layouts. 

We have included a english layout, but is not as tested and developed as
the spanish one. 

To use passwords you need to edit run.js to set the password, IIRC there
is no url parameter for the token, but can be aded easily. 

> Rough edges aside, I did note that it was visibly faster than the
> current html5 client for normal usage. I presume that all your
> optimization of image handling pays off nicely. I also presume it has
> better support for Windows guests (that would not be too difficult :-/).

There are three reasons why it is faster. The first one is because of
the image handling optimization. The second one is because it works with
qxl activated. The third one is because of the graphical pipeline with
almost zero copy. For example, in the queue for the receiving socket, if
look at it (socketqueue.js, inside network) there a shadow copy
implemented in javascript to avoid copy and gc work. 

It has been optimized a lot for windows with qxl enabled, in fact with
windows + qxl and using chromium, the performance is quite close to the
native spice client implementation. 

In linux, it is a bit slow on gnome with compositing because of obvious
reasons, but is very fast with kde4 with compositing disabled. In fact
with kde4 without compositing and using the xorg render the performance
is even better than in windows. 

One of our current products use kde4 without compositing and the other
one uses windows with qxl enabled, this is why we optimized a lot for
this environments/configurations. 

> It's lacking some recent developments; notably support for Opus and
> support for file transfer, although I don't think either of those would
> be especially hard to add. My most recent video work around rate
> control seems to give the current spice-html5 an edge in video
> performance, at least with Xspice, but that, too, would likely be easy
> to add to your client.

Wow, thats very interesting. With a linux client using the last chromium
connecting to a remote windows guest the performance of video is way
better with spice web client than with spice-html5. Maybe you have
optimized more for Xspice? We have stil not tested Xspice, neither
optimized for it. 

I don't remember how spice-html5 handles video frames, we do it by using
createObjectUrl to not having to encode the jpeg blob with urlencode,
this increased the video performance a lot. 

You are right about recent spice features, we would like to have support
for the most recent features, but we invested a lot in performance
because of requirements of our customers... They were more interested in
better performance than in more features, even to a crazy extent. 

> I am a bit frustrated that you've sprung this, fully formed, upon us.
> The spice-html5 client has been developed, in public, and collaboration
> has been very welcome these past 3 years. But I do prefer your
> contribution to you keeping it closed instead :-).

Personally I would have prefered to work with you guys improving the
spice-html5. However we started this is a startup and our investors
disliked opensource and free software a lot... So for us it was
impossible to collaborate with you. 

Later, we were acquired by Telefonica, the biggest Spanish Telco. We
continued to develop our products as telefonica owned company.
Telefonica is an active contributor in the Open Source community, its a
red hat partner and has a positive view about FOSS. 

It took us some time and meetings with Telefonica before we reached an
agreement for opensourcing a piece of software like this. I understand
that this could have been done better. 

Of course, as a developer myself, I really love to be able to contribute
with my work of the last 2 years in optimizations of all kinds and
support for lots of spice internals (glyphs, scaling, clipping, masking,
etc). 

> Do I guess correctly that this has been your company's main user
> interface for the past several years? Does that imply that it's been in
> fairly heavy use for some time now?

More or less. We have developed a eyeos-agent (like spice-agent) that
uses rabbitmq and through this we send coordinates and positions of
remote windows. Depending on the customer, we display the entire
linux/desktop or just the application that is running there. 

But yes, it is has been used heavily for the last 2 years. 

> If you don't mind my asking, what are your intentions with this? Are
> you hoping to have this become the defacto html5 client for Spice? Are
> you willing to maintain it and take on community contributions?
> 
> I note the attribution clause in your license. As it stands now, I
> don't think that would cause any trouble (because of the 'however' of 5
> (d) of the agpl). But it would probably be useful to get a clear
> expression of your intent - is it the case that you are willing to
> contribute this only so long as the eyeos logo is prominently displayed
> by any one choosing to deploy it?

Our intentions are very simple. We want this to become the defacto html5
client for spice. Of course we want to maintain it and develop it
openly. Aside from our obvious personal preferences for FOSS the main
reason to opensource it is to develop it in community and of course, we
are very excited to discuss the next steps with you and anyone
interested in web support for spice :) 

And no, we are not willing to have an eyeos logo everywhere this client
is used. In fact there is no need for you to display an eyeos logo to
use this. 

We choosed AGPL because it protects the spice web client from the ASP
loophole. We don't want en eyeos logo or something like this displayed
every time this client is used, we just don't want for example a third
party company adding support for opus in a private product of its own
and not contributing it since this can be used from a service provider
(ASP loophole in gpl and similar licenses). 

However, we are open to discussions about the license if you feel this
can be a problem for reasonable scenarios. 

I hope this clarified a bit our intentions and position, i know this has
been done a bit late :) 

Best regards, 

joca 

On 2015-10-29 17:12, Jeremy White wrote: 

> On 10/29/2015 06:38 AM, jose at eyeos.com wrote: 
> 
>> Hi,
>> 
>> We are very glad to announce that today we have released under AGPL3
>> license our full featured (audio, video, clipboard, qxl advanced
>> graphics, etc) spice web client.
>> 
>> The github of the project:
>> 
>> https://github.com/eyeos/spice-web-client [1]
>> 
>> Comments are welcome!
> 
> Wow! That is astonishing, and well done, congratulations.
> 
> I've played with it a bit; I had some issues with keyboard problems, and
> it wasn't immediately obvious how to use passwords or ssl. Of course, I
> suspect those are issues that are relatively easy to address.
> 
> Rough edges aside, I did note that it was visibly faster than the
> current html5 client for normal usage. I presume that all your
> optimization of image handling pays off nicely. I also presume it has
> better support for Windows guests (that would not be too difficult :-/).
> It's lacking some recent developments; notably support for Opus and
> support for file transfer, although I don't think either of those would
> be especially hard to add. My most recent video work around rate
> control seems to give the current spice-html5 an edge in video
> performance, at least with Xspice, but that, too, would likely be easy
> to add to your client.
> 
> I am a bit frustrated that you've sprung this, fully formed, upon us.
> The spice-html5 client has been developed, in public, and collaboration
> has been very welcome these past 3 years. But I do prefer your
> contribution to you keeping it closed instead :-).
> 
> Do I guess correctly that this has been your company's main user
> interface for the past several years? Does that imply that it's been in
> fairly heavy use for some time now?
> 
> If you don't mind my asking, what are your intentions with this? Are
> you hoping to have this become the defacto html5 client for Spice? Are
> you willing to maintain it and take on community contributions?
> 
> I note the attribution clause in your license. As it stands now, I
> don't think that would cause any trouble (because of the 'however' of 5
> (d) of the agpl). But it would probably be useful to get a clear
> expression of your intent - is it the case that you are willing to
> contribute this only so long as the eyeos logo is prominently displayed
> by any one choosing to deploy it?
> 
> Cheers,
> 
> Jeremy
> _______________________________________________
> Spice-devel mailing list
> Spice-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel [2]

 

Links:
------
[1] https://github.com/eyeos/spice-web-client
[2] http://lists.freedesktop.org/mailman/listinfo/spice-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/spice-devel/attachments/20151030/8062dc14/attachment-0001.html>