Indeed, Xaja relies on the keeping of an open connexion between the server and the browser. In fact, it uses, the Comet approach (which is a pain to implement in Javascript because the IE code and the Firefox code are completely different). (more information here: http://www.thecodingmachine.com/cmsDoc/xaja/trunk/architecture.html) The whole idea behind Xaja is to built a complete framework on top of the Comet-like javascript library that will enable the developer to write as few Javascript as possible. So, indeed, through the "XajaController" object, we are implementing a "data driven programming" library on top of the classical request/response HTTP protocol. Regarding performances: Indeed, since a connexion is kept open for each browser, this consumes a few connexions on the server (that's not a big problem). Each process also takes some memory. Xaja is still in an early stage of development and I haven't had the opportunity to run a full performance test, but basically, right now, I can tell that a simple applications takes 5 Mo of RAM per client. Which means that for 100 concurrent users, you need 500 Mo of RAM on your server. Now, the vast majority of the servers have less than 100 concurrent users, and at this early point in the development cycle of Xaja, I wouldn't recommend installing Xaja on a server that has more than 100 concurrent users! ;) Regards, David. Nathan Nobbe a écrit : > I understand the use of AJAX to only update a subset of the DOM on a page, > rather than rebuild the entire page. What i was getting at though is > eliminating > the busy-wait model by using the Observer pattern to push changes to the > client > only when the data has changed on the server side. This is decidedly more > efficient in general and is more commonly referred to as *event driven > programming* > or *data driven programming*. it sounds like the only way to implement such > a model > over HTTP is by keeping the connection open; which in some circumstances may > be appropriate. > I have to say though, I never thought of using busy waiting to update just a > portion > of the DOM. It seems like almost a no-brainier, but since i havent worked > w/ AJAX > much it just never crossed my mind. That sounds like the most practical > approach in > general. > > -nathan > > > On 7/13/07, Tijnema <tijnema@xxxxxxxxx> wrote: >> >> On 7/13/07, Nathan Nobbe <quickshiftin@xxxxxxxxx> wrote: >> > > On 7/13/07, Robert Cummings <robert@xxxxxxxxxxxxx> wrote: >> > > This isn't possible since you can't request a connection to the >> client's >> > > machine. Only the other way around. >> > >> > hmm... in that case perhaps the open connection could be employed and >> > the feature used selectively; only on certain pages for instance ? >> > im thinking mainly of a monitoring page; like an app that shows a >> servers >> > state, >> > or stock quotes or something. >> > the main reason i dont like a javascript timer refreshing the page is >> > sometimes you >> > dont want the whole page refreshed; especially when halfway through >> filling >> > out a >> > form on the page ;) >> > >> > -nathan >> >> Well, that's why AJAX is there, you do a check to a server to see if >> there's any new data to parse, if so, then you update (and probably >> only one or two divs on your site, and not the whole page) >> >> Keeping connection open isn't quite bad for sites that are visited a >> lot, as for each connection, a new port is opened to handle a client >> connection. While you think you're connected to port 80, it is >> actually redirected to another port (mostly from 3000 onwards). So, if >> you have a lot of visiters, you might reach the limit of ports, 65536 >> (0-65535). Some of them are already in use, so you end up to have a >> limit of about 65530 connections to keep open. For a normal site this >> isn't a problem, but if you count on shared hosts, with let's say 20 >> sites, then they can all handle about 3200 connections. Half of the >> users has probably more then one window open, which means another >> connection. So you end up to have a maximum of about 2000 visiters at >> same time for each site. >> >> >> Tijnema >> >> > >> > On 7/13/07, Robert Cummings <robert@xxxxxxxxxxxxx> wrote: >> > > >> > > On Fri, 2007-07-13 at 14:59 -0400, Nathan Nobbe wrote: >> > > > > On 7/13/07, Robert Cummings <robert@xxxxxxxxxxxxx> wrote: >> > > > > I haven't looked at the code for Xaja and in no way do I want to >> > > > > subtract from its potential, but I'm going to guess that in some >> way >> > > > it >> > > > > holds the HTTP connection open and as such is an expensive >> feature. >> > > > > Also, I'm not entirely sure, but isn't that the principle that >> > > > Comet >> > > > > uses? >> > > > >> > > > As i said ive only imagined such a feature. In my imagination i >> > > > wonder if it is possible to >> > > > track the clients address in a data structure within the >> application. >> > > > Then a connection could be >> > > > established whenever a push was needed. >> > > >> > > This isn't possible since you can't request a connection to the >> client's >> > > machine. Only the other way around. >> > > >> > > > I also think the app would have to track the last page >> > > > a user requested in order to realize such an implementation. This >> > > > *should* be feasible using >> > > > sessions because whenever the client makes a new request the last >> page >> > > > variable could be updated. >> > > > I havent seen nor heard of Comet; would you mind providing a link? >> > > >> > > http://ajaxian.com/archives/comet-a-new-approach-to-ajax-applications >> > > >> > > Cheers, >> > > Rob. >> > > -- >> > > ........................................................... >> > > SwarmBuy.com - http://www.swarmbuy.com >> > > >> > > Leveraging the buying power of the masses! >> > > ........................................................... >> > > >> > >> >> >> -- >> Vote for PHP Color Coding in Gmail! -> http://gpcc.tijnema.info >> > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
