El 16/07/13 14:04, Ali Lown escribió: > On 16 July 2013 12:48, Vicente J. Ruiz Jurado <v...@ourproject.org> 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 kune.cc) 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 support. 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. BR, -- Vicente
