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.
