Hi Vincent, I'm not convinced either that you need to go beyond traditional REST/HTTP to achieve your goal efficiently. Another optimization that could come into play is conditional GET to make sure that you only retrieve a representation if it has changed since last request.
Also, using long polling will require connections/socket to stay open for a while, also increasing the scalability requirements at network level, compared to short lived connections. Regarding the manipulation of the DOM, you could also provide to your web designer a well defined JavaScript API that would do all the heavy lifting of issuing the AJAX request, processing the response, parsing the DOM, etc. Best regards, Jérôme Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com -----Message d'origine----- De : Vincent Nonnenmacher [mailto:[EMAIL PROTECTED] Envoyé : vendredi 3 octobre 2008 08:01 À : [email protected] Objet : Re: advice needed for using glassfish as intermediation server to implement Restlet comet/bayeux style architecture John D. Mitchell a écrit : > On Thursday 2008.10.02, at 01:25 , Vincent Nonnenmacher wrote: > [...] >> I've choosen first to implement an ajax inerface to it for >> demonstration purposes >> so I quickly wrote several Quick&Simple samples using jQuery. > > Cool! thanks to jQuery & Restlet, sure having a 20 lines of javascripts and total freedom for web developers to make their own phone dashboards will be a plus. > >> But looking at the bandwith used by exchanges between client and >> Restlet server I quickly see the limits >> for this 'polling' approach (for example a simple queues management >> console for monitoring several asterisk >> servers's calls queues are around 3 request/s and even if each grab >> 1-5 ms of time >> to serve the approach will push linearly on the server as the client >> augment * by the polling frequency) > > I'm confused... What are your dashboard clients doing that need to > sustain 3 RPS (requests per second)? I.e., why do you need fast > updating for a dashboard app? It's not like this is some sort of > critical systems control panel (for e.g., an assembly line, nuclear > power plant, medical monitoring, etc.). if you look at the breakdown of queues, having members, calls being held, active calls coming and watching agents behaviour you got that number as each one is making its own timed poll loop, so this 3 req/s is on a 'small call-center'. As we do 'distributed' queues handling on several servers, you double this when a dashboard monitor two systems. Its true however that the size of the payload will augment with the number of agents/queues with the same frequency. But it clearly show the limit of 'polling'. Doing long request polling will be far better (and in the easy reach of Restlet) at the cost of a waiting thread on the Rest server, but definitly a publish/subscribe mechanism like bayeux, will have a more natural 'impedance match' than this approach. > >> I can quickly conclude that a generic console that will show you all >> your company phones >> status multiplied by the number of people watching them is a dead end >> solution >> (think about 500 users watching each other phones and how this scale) > > You should be able to update your resources on a periodic basis and > treat them as a cache between updates. I.e., don't do any calculations > on the requests. its how I do it ad why the cpu load is not so important, but i was concerned in the balance of expressing a clean REST syntax exposing this representation and the fact that to limit the number of requests, I will be obliged to pass along more 'collected' information in a balance betweenI have take better Representation vs number of requests. For example in asking for a (phone/device/extension) status in order to show a green/red light of a person availability and making a loop asking for those elementary information and a plural (or list syntax) in the query to have a long list of informaiton and then express the loop inside the DOM manipulation. > > Also, if you have lots and lots of connections to manage then you can > always add another, simple tier in front of the actual "master" server > to deal with the connection fan out. > > Depending on what information you're passing back at the moment, you > should also be able to do bulking of requests... I.e., if you're doing > lots of small requests for individual pieces of data you can create a > much smaller number of requests for bundles of data. > You're absolutly right but at the expense of a more complex handling on the client side. I wish I could have a so simple bunch of samples that even a graphic designer could handle a complex dashboard using copy&paste, without being too much concern about DOM manipulation (I have found that web designers have difficulties with those 'empty' DOMs document manipulated by some magicall javascript in front ;-) Having the choice of being called by the server (or get a long delayed response) will be much more easier on the REST syntax and DOM manipulation by more web designers/programmers.
