<brief promo plug> Especially in the latter case of developing nations - but also for mobile users in general - enabling offline modes with synchronisation after an indefinite period is a must. </brief promo plug> John
All the best, John Blossom email: jblos...@gmail.com phone: 203.293.8511 google+: https://google.com/+JohnBlossom On Tue, Jul 16, 2013 at 9:12 AM, Vicente J. Ruiz Jurado <v...@ourproject.org > wrote: > 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 >
