Thanks Chris, Yeah I Agree, option 2 seems to be the best way to go. Although, I have been doing a little research into HTML 5 WebSockets.
Has anyone used WebSockets with GWT/PHP? Is there a reason why there is very little content available on the subject? It seems that most major browsers already support HTML 5 to some degree. When it comes to server communication WebSockets seem like a good idea to me? On Feb 27, 4:49 pm, Chris Lercher <[email protected]> wrote: > Hi, > > I haven't done the exact setup you mention, but I'd certainly go for > option 2) or something similar. > > In an Ajax app, you can have a lot of things going on simultaneously, > and I think it will be much easier this way, when the client just > tells the server: Now I'm interested in this. Now additionally in > this. Now I have no more interest in the first one. etc. > > A lot of current browsers offer more than two simultaneous requests > anyway (for current Firefox and IE8 it's six HTTP1.1 connections, > right?), and as long as you design it such, that it can still work > with two requests, you should be fine, I hope. > > Chris > > On Feb 27, 4:35 pm, AndyB <[email protected]> wrote: > > > Hi, I am in the initial planning stages for a community based website > > that I plan on developing with GWT and a PHP Backend. I was wondering > > if anyone could offer some architectural advice? > > > The application will have several activities that the user can switch > > between, such as forums/topics or viewing/posting blogs.. ect. There > > will also be static widgets on the page that will require to listen > > for updates from the server. Such as a shoutbox and a users online > > list. > > > Unfortunately my server does not support servlet containers so no RCP. > > I need to use PHP. > > I am leaning towards using long polling, seems like a good idea. Send > > a request to a PHP script and POST a list of activities the user is > > doing such as viewing a forum, and then when something on that forum > > updates the PHP can return with the update. > > > The only problem with this is what if the user changes activities > > after the request is made. I.E: Client sends a request to be updated > > about a certain forum, but then starts browsing another. > > > I can come up with two ways around this.. > > > 1) When the user changes activity.. kill the request and start a new > > one. > > > 2) Have two requests. One long polling request waiting for updates, > > not sending what the user is doing. When the user changes activity, a > > second request to another PHP script updates the users SESSION to what > > they are doing, then when the long polling request gets the update in > > session it checks for those updates instead. > > > Both have their advantages and disadvantages. The first one only ties > > up one of the 2 connection limit imposed by most browsers, but had a > > lot of extra network overhead with killing/resending requests. The > > second one involves using up both of the 2 connections from time to > > time. Although the second connection would not last, just update the > > session info. > > > Has anyone encountered such a design problem? Could someone offer some > > advice on how I should tackle this? > > > Thanks for your time in reading. > > Andy -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
