incubator-wave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vicente J. Ruiz Jurado" <>
Subject Re: Feedback from Incubator Vote
Date Tue, 16 Jul 2013 13:12:55 GMT
El 16/07/13 14:04, Ali Lown escribió:
> On 16 July 2013 12:48, Vicente J. Ruiz Jurado <> wrote:
>> El 15/07/13 19:12, Ali Lown escribió:
>>> Deletion:
>>> I feel that none of these libraries serve any purpose now, and should
>>> be removed.
>>> - codegen/SocketIO (superseded by Websockets, could-be-argued to keep
>>> for legacy situations, but I don't feel it is worth the maintenance
>>> effort)
>>> - runtime/SocketIO ditto
>> When websocket it not available or is not working, the webclient uses
>> socketio as a fallback (many times, because the client is under a proxy
>> that blocks websocket connections, or because the browser is not
>> up-to-date).
> I am aware of the uses of Socket.IO, but fail to see them as worth supporting:
> 1) Outdated browser -> Why maintain support for out-of-date browsers?
> This is the IE6 argument again...
> 2) 'Proxy' -> If by this you mean an open 'web proxy' - why are we
> supporting that?
>                   Anybody attempting to 'hide' their IP would be using
> a VPN which does not have this problem...
>                   Are there any other uses for a 'web proxy'?
>               -> If by this you mean an out-of-date Corporate proxy -
> why are we supporting this case?
>                   (IIS8 added support for Websockets for all modern
> corporations stuck using Windows, Squid 2.X+3.X support Websockets
> [except in 'interception mode'])
>                   [Use of SSL will get Websockets through all but the
> meanest of firewalls, since the only possible situation breaking the
> packets then is a firewall performing DPI which is manipulating SSL'd
> packets on-the-fly!]
>                   If you are using Wave from behind your corporate
> firewall there are 2 situations:
>                   1) It is company-related work -> In which case they
> will have already done the work to get Wave through their firewall
>                   2) It is NOT company-related work -> In which case
> why is it being done at their workplace, and why should we support it?
> Ali
> PS. Thanks for the patch, depending on the response to this, I may
> need to use it.

With some of our public wave servers (for instance we had
received feedback of users with connections issues:
- from corporations using hardware and/or software not websocket capable
(I think that even Yuri was suffering this problem in his job)
- from universities and libraries with hard restrictions on their users
Internet connections
- from users in poor countries (in Central America and Asia) where
Internet providers use proxies to minimize the bandwidth usage.

Also some browsers of tablets & mobiles don't have correct websocket

This is why I implemented the fallback use of socketio and I try to  fix
the bugs I found in socketio, because we see that users from public wave
servers use/need it. So from our point of view and from our daily
experience a websocket fallback is very needed.

I was looking for an alternative to socketio several times (atmospehere,
cometd, gnisio, etc), but I couldn’t provide yet a patch with a more
updated alternative to socketio-gwt.


View raw message