Ajax - Asynchronous Javascript + XML
February 21, 2005 8:59 AM Subscribe
Ajax: A New Approach to Web Applications. From our own JJG, a look at the next big thing in web app interfaces. Link via some guy named Matt. Time to start studying XMLHttpRequest.
The depressing thing is that you can't use XMLHttpRequest to access files on another domain.
That ruins a lot of fun ideas.
posted by smackfu at 9:09 AM on February 21, 2005
That ruins a lot of fun ideas.
posted by smackfu at 9:09 AM on February 21, 2005
Given the lessons of a few projects I've worked on, this approach is actually a lot EASIER on your server and bandwidth than other solutions. Sure, it can be abused and result in nonstop thrashing. But it's a lot less brutal than round-tripping the entire page, or implementing the entire web app in flash or what not, whenever the user enters data and needs contextual information updated to reflect it.
posted by verb at 9:10 AM on February 21, 2005
posted by verb at 9:10 AM on February 21, 2005
This seems like it makes more sense if you're running a very specific, single application, like google maps.
If you are developing an "application" with hundreds of pages doing very different things, you're going to have to build tons of those Ajax engines to handle all the different interfaces.
So, basically if your application workflow is meant to bounce around between lots of different interfaces, I don't think this will help much, which is a shame.
posted by frufry at 9:14 AM on February 21, 2005
If you are developing an "application" with hundreds of pages doing very different things, you're going to have to build tons of those Ajax engines to handle all the different interfaces.
So, basically if your application workflow is meant to bounce around between lots of different interfaces, I don't think this will help much, which is a shame.
posted by frufry at 9:14 AM on February 21, 2005
But does that "essay" really say anything ? Seems to me Jesse James Garrett, founder of Adaptive Path just needed a reason to publish his new wizz-bang code name for the communications technique.
Ajax? Come on.
posted by shoez at 9:22 AM on February 21, 2005
Ajax? Come on.
posted by shoez at 9:22 AM on February 21, 2005
Shoez, you should know the first thing you need for technology adoption is a cool name. Ajax meets both cool name qualifications: you can pronounce it and it has an "x" in it.
posted by sexymofo at 9:29 AM on February 21, 2005
posted by sexymofo at 9:29 AM on February 21, 2005
That's not true frufry. At least I don't think it's true, seeing as on a site I work on you get bounced around between a lot of interfaces, and we use "remote scripting" techniques all over the place.
posted by ericost at 9:29 AM on February 21, 2005
posted by ericost at 9:29 AM on February 21, 2005
Speaking as a developer, this is a fabulous way to create even-harder-to-maintain applications. If you're Google, with a small number of (front-end) apps and a large number of developers, then maybe this doesn't matter. But for the smaller shop, I think it would be a nightmare.
posted by Slothrup at 9:30 AM on February 21, 2005
posted by Slothrup at 9:30 AM on February 21, 2005
The minute I saw Google Suggest I went off and wrote a demo for my company using XMLHttpRequest. The demo illustrated functionality that I had just weeks ago patiently explained to a client was not feasible on the web. Oops.
Everyone was totally floored. It's amazing how people have become conditioned to accept the limited functionality of web-based interaction, compared to the UI possibilities we used to have using desktop apps.
But yeah, "Ajax"? I hunted around the page expecting that he was offering an actual library or software package. My demo took just an hour to code, starting from zero knowledge. There's not enough technology there to require a brand name.
posted by nev at 9:32 AM on February 21, 2005
Everyone was totally floored. It's amazing how people have become conditioned to accept the limited functionality of web-based interaction, compared to the UI possibilities we used to have using desktop apps.
But yeah, "Ajax"? I hunted around the page expecting that he was offering an actual library or software package. My demo took just an hour to code, starting from zero knowledge. There's not enough technology there to require a brand name.
posted by nev at 9:32 AM on February 21, 2005
I also have to say: this is not a new approach at all. Many people have been doing the things described in that article for years. What's relatively new is major companies adopting the approach, and in the case of Google, implementing it amazingly well.
posted by ericost at 9:33 AM on February 21, 2005
posted by ericost at 9:33 AM on February 21, 2005
I was astounded by Google Suggest. But less so when I decided to search for "pants."
Go ahead. Type the letter "P".
Bwa- Bwa ha haaa!
posted by Baby_Balrog at 9:35 AM on February 21, 2005
Go ahead. Type the letter "P".
Bwa- Bwa ha haaa!
posted by Baby_Balrog at 9:35 AM on February 21, 2005
Oh, no doubt verb. Like anything "Ajax", (using Javascript with an iFrame/XMLHttpRequest/XML-RPC/ etc. to roundtrip data only) is just a tool, neither good or evil.
However, google's two recent "cool tools" (suggest and maps) rely on having a high performance, responsive network behind them.
posted by alana at 9:40 AM on February 21, 2005
However, google's two recent "cool tools" (suggest and maps) rely on having a high performance, responsive network behind them.
posted by alana at 9:40 AM on February 21, 2005
typical. geeks and corporate web-apps designers have been doing this for years. the first time i built an "ajax" web-app was in 2001/2002, using IFRAME/ILAYER remote scripting (yep, ILAYER, because it had to work in Netscape 4.x.), and I was far from the first person to do it -- I found out about these techniques through simple web searching.
Now, Adaptive Path comes along and slaps a four-letter acronym on a well-established technique, and proceeds to overcharge for countless seminars and "white papers" on their "revolutionary concept". the whole article is a bit disengenious - there is undeniably a sense that they're taking credit for this approach, but they've done nothing but slap a marketing buzzword on it.
not only that, the article is somewhat innacurate. from what i understand, google maps actually uses the IFRAME "remote scripting" method, not XMLHTTPRequest, because of the browser back-button issues with XMLHTTPRequest, as evidenced by Gmail.
frufry, it's quite possible to use this on apps with different interface screens. the remote scripting framework is very eaily generalized, so you can use regular HTTP postbacks to navigate between interface screens that are fundamentally different. generally, using the DOM, all the remote scripting interface needs to do is call a server side page, request a chunk of data, and be told where to place that data in the interface. it's not really even necessary to use XSLT, you can generate well-formed XHTML on the server insted of XML.
here's an article from January 2002 which gives a pretty good overview of these "revolutionary" concepts.
i'm by no means trying to downplay the incredible usefulness of all the recent apps to use this technique. i just find many of the "user experience guru" shops' approach to selling themselves a bit distasteful.
on preview, what everyone else said.
posted by dvdgee at 9:41 AM on February 21, 2005
Now, Adaptive Path comes along and slaps a four-letter acronym on a well-established technique, and proceeds to overcharge for countless seminars and "white papers" on their "revolutionary concept". the whole article is a bit disengenious - there is undeniably a sense that they're taking credit for this approach, but they've done nothing but slap a marketing buzzword on it.
not only that, the article is somewhat innacurate. from what i understand, google maps actually uses the IFRAME "remote scripting" method, not XMLHTTPRequest, because of the browser back-button issues with XMLHTTPRequest, as evidenced by Gmail.
frufry, it's quite possible to use this on apps with different interface screens. the remote scripting framework is very eaily generalized, so you can use regular HTTP postbacks to navigate between interface screens that are fundamentally different. generally, using the DOM, all the remote scripting interface needs to do is call a server side page, request a chunk of data, and be told where to place that data in the interface. it's not really even necessary to use XSLT, you can generate well-formed XHTML on the server insted of XML.
here's an article from January 2002 which gives a pretty good overview of these "revolutionary" concepts.
i'm by no means trying to downplay the incredible usefulness of all the recent apps to use this technique. i just find many of the "user experience guru" shops' approach to selling themselves a bit distasteful.
on preview, what everyone else said.
posted by dvdgee at 9:41 AM on February 21, 2005
XMLHTTPRequest is fantastic.
It's the hot little object behind all of the slickest new html/css/javascript only websites. And it doesn't require a large team of programmers to be able to use it, one competent programmer is plenty.
posted by mosch at 9:47 AM on February 21, 2005
It's the hot little object behind all of the slickest new html/css/javascript only websites. And it doesn't require a large team of programmers to be able to use it, one competent programmer is plenty.
posted by mosch at 9:47 AM on February 21, 2005
this is a fabulous way to create even-harder-to-maintain applications.
Why? Assuming you've decoupled your user interfaces from everything else, why isn't this simplifying things?
posted by yerfatma at 9:48 AM on February 21, 2005
Why? Assuming you've decoupled your user interfaces from everything else, why isn't this simplifying things?
posted by yerfatma at 9:48 AM on February 21, 2005
Baby_Balrog: if you'd have just posted the whole search string you were looking for: "pants, someone that seems to never wear under", Google Suggest was right on the money after just typing one letter! All Hail Google!
Whether Ajax is a new concept or not (and certainly from previous posts that answer seems to be a definitive no), the concept sure is intriguing. None of my web/db apps that I work on really are crying out for this, but I'll probably end up geeking around with it anyway...
posted by mcstayinskool at 9:57 AM on February 21, 2005
Whether Ajax is a new concept or not (and certainly from previous posts that answer seems to be a definitive no), the concept sure is intriguing. None of my web/db apps that I work on really are crying out for this, but I'll probably end up geeking around with it anyway...
posted by mcstayinskool at 9:57 AM on February 21, 2005
The only reason to aggressively pursue this technology now, as opposed to 2-3 years ago when it was first introduced, is that we're finally in an IE 6/Firefox/Safari world, rather than an IE 5/6/Netscape 4/6 world.
Plus there's no better way to convince your boss/client/salesperson that an approach is right than to say, "Google does it."
posted by nev at 10:08 AM on February 21, 2005
Plus there's no better way to convince your boss/client/salesperson that an approach is right than to say, "Google does it."
posted by nev at 10:08 AM on February 21, 2005
I'm fascinated that Paris Hilton's name is the Google representation
(goosentation?) of the letter "P". It has to be some measurement of
collective consciousness. So. I suppose we could compile some sort
of children's book based on the first result returned by Google
Suggestions.
A is for amazon, a place to buy books. B is for Best Buy, a
place to buy status. C is for CNN, what gives us our truths. D is
for dikshunary, a spellerin' apuratus. E is for EBay, a place to buy.
F is for Firefox, WOO FIREFOX RULES! G is for games, oh, how the
time flies. H is for hotmail, free email. How cool. I is for Ikea,
build it yo'self. J is for jokes, I'm done coming up with stuff. K
is for Kazaa, L is for lyrics, M is for Mapquest, N is for news, O is
for "online dictionary," god. Duh. P is for Paris Hilton (I know.)
Q is for quotes. R is for recipes. S is for Spybot. T is for Tara Reid. U is for UPS.
V is for Verizon. W is for weather. X is for XBox. Y is for Yahoo. Z is for Zip Codes.
So. Tara Reid and Paris Hilton are the two humans to make the list. I wonder what this means.
I also wonder what the algorithm google uses to line up the first selection is. Probably has something to do with recent popularity.
posted by Baby_Balrog at 10:33 AM on February 21, 2005
(goosentation?) of the letter "P". It has to be some measurement of
collective consciousness. So. I suppose we could compile some sort
of children's book based on the first result returned by Google
Suggestions.
A is for amazon, a place to buy books. B is for Best Buy, a
place to buy status. C is for CNN, what gives us our truths. D is
for dikshunary, a spellerin' apuratus. E is for EBay, a place to buy.
F is for Firefox, WOO FIREFOX RULES! G is for games, oh, how the
time flies. H is for hotmail, free email. How cool. I is for Ikea,
build it yo'self. J is for jokes, I'm done coming up with stuff. K
is for Kazaa, L is for lyrics, M is for Mapquest, N is for news, O is
for "online dictionary," god. Duh. P is for Paris Hilton (I know.)
Q is for quotes. R is for recipes. S is for Spybot. T is for Tara Reid. U is for UPS.
V is for Verizon. W is for weather. X is for XBox. Y is for Yahoo. Z is for Zip Codes.
So. Tara Reid and Paris Hilton are the two humans to make the list. I wonder what this means.
I also wonder what the algorithm google uses to line up the first selection is. Probably has something to do with recent popularity.
posted by Baby_Balrog at 10:33 AM on February 21, 2005
This all started out with using hidden iframes for what was called Remote Scripting with Iframes (see O'Reilly Article from 2002 or this Apple Developer article).
Since then people clued into XMLHttpRequest, which although not a standard, is supported by all the major browsers. A lot of toolkits already exist for it, the one I'm most familiar with is domapi (note, I've contributed a bit of code to them before) which in version 4 includes full XMLHttpRequest RPC functionality through a simple interface including timeouts, retries and whatnot.
Having implemented a few homebrew solutions for my last company using this, I can assure you that it's the next big thing until XForms or whatever replaces it. It doesn't put a burden on the server, makes saving complicated pages (think online purchase orders with workflow rules and whatnot) much easier, and for the developer you don't have to waste as much time making sure that you maintain state after each roundtrip.
Also, just as important is the use of JavaScript Object Notation (JSON) which allows you to do the same sort of thing, still using the XMLHttpRequest object, but return actual JavaScript objects with it. I've written introspection.toJSON() methods in Java that will take any bean and convert it into JSON in an instant, and it cuts down on the overhead of XML. Very cool stuff.
I had my doubts about all of this at first, but it ended up working really well, and then when I saw that google was using it in gmail, and later google suggest, it was real vindication that this isn't just a hack.
posted by furtive at 10:44 AM on February 21, 2005
Since then people clued into XMLHttpRequest, which although not a standard, is supported by all the major browsers. A lot of toolkits already exist for it, the one I'm most familiar with is domapi (note, I've contributed a bit of code to them before) which in version 4 includes full XMLHttpRequest RPC functionality through a simple interface including timeouts, retries and whatnot.
Having implemented a few homebrew solutions for my last company using this, I can assure you that it's the next big thing until XForms or whatever replaces it. It doesn't put a burden on the server, makes saving complicated pages (think online purchase orders with workflow rules and whatnot) much easier, and for the developer you don't have to waste as much time making sure that you maintain state after each roundtrip.
Also, just as important is the use of JavaScript Object Notation (JSON) which allows you to do the same sort of thing, still using the XMLHttpRequest object, but return actual JavaScript objects with it. I've written introspection.toJSON() methods in Java that will take any bean and convert it into JSON in an instant, and it cuts down on the overhead of XML. Very cool stuff.
I had my doubts about all of this at first, but it ended up working really well, and then when I saw that google was using it in gmail, and later google suggest, it was real vindication that this isn't just a hack.
posted by furtive at 10:44 AM on February 21, 2005
BabyBalrog, I think your post would have made an excellent FPP.
posted by furtive at 10:46 AM on February 21, 2005
posted by furtive at 10:46 AM on February 21, 2005
This is actually a very bad design choice and it pretty much goes against the fundamental nature of the web which is based on URLs (and all the good stuff that comes with URLs like bookmarkability, security, caching). Yet another fad that many will abuse and few will use correctly.
posted by nixerman at 11:01 AM on February 21, 2005
posted by nixerman at 11:01 AM on February 21, 2005
Furtive, thanks, but as the author of the Iframe article, I must say that that is not where it started. Brent Ashley was releasing Remote Scripting goodies in 2000.
First place I saw the technique in use on a major site was Netflix, where you could rate a movie without reloading the page. This was sometime in 2000, IIRC. I did something similar for rating entries on the 5k contest site in 2001. We also had an in-situ html editor for the 5k site which allowed us to change site copy just by clicking on the text, making changes and hitting "submit".
posted by ericost at 11:09 AM on February 21, 2005
First place I saw the technique in use on a major site was Netflix, where you could rate a movie without reloading the page. This was sometime in 2000, IIRC. I did something similar for rating entries on the 5k contest site in 2001. We also had an in-situ html editor for the 5k site which allowed us to change site copy just by clicking on the text, making changes and hitting "submit".
posted by ericost at 11:09 AM on February 21, 2005
Furtive: My experience (note the singular) with FPPing convinced me that I'd rather lurk than take the risk of a MetaBashing from more weathered MeFites.
I guess if you can't make two links out of it, it isn't worth FPPing. However, you're welcome to give it a go.
posted by Baby_Balrog at 11:12 AM on February 21, 2005
I guess if you can't make two links out of it, it isn't worth FPPing. However, you're welcome to give it a go.
posted by Baby_Balrog at 11:12 AM on February 21, 2005
Baby_Balrog: I guess if you can't make two links out of it, it isn't worth FPPing.
Nonsense. Check my link history. Most end up with no bashing.
posted by Gyan at 11:20 AM on February 21, 2005
Nonsense. Check my link history. Most end up with no bashing.
posted by Gyan at 11:20 AM on February 21, 2005
This is actually a very bad design choice and it pretty much goes against the fundamental nature of the web which is based on URLs (and all the good stuff that comes with URLs like bookmarkability, security, caching). Yet another fad that many will abuse and few will use correctly.
For document-centric web content, yes. For applications, no. That "fundamental nature of the web" stuff is not very friendly to applications in general.
For what it's worth, we've been doing managed-state client interfaces in HTML using similar techniques for years - since Netscape 3.0 was generally available.
posted by me & my monkey at 11:34 AM on February 21, 2005
For document-centric web content, yes. For applications, no. That "fundamental nature of the web" stuff is not very friendly to applications in general.
For what it's worth, we've been doing managed-state client interfaces in HTML using similar techniques for years - since Netscape 3.0 was generally available.
posted by me & my monkey at 11:34 AM on February 21, 2005
My prediction is that this will end up hugely favouring Mozilla. I'm doing a lot of work on an intranet application using exactly this model (and it was written in late 2002). A good Javascript debugger is critical once you start doing this kind of thing in the client, and my word, IE is a pain in the arse in this department. if (debug) alert("got to line 145!") everywhere...
It's also going to be demanded, absolutely demanded by all the management types. I've lost count of the patient explanations I've had to give of the web model, the need to post back to the server, the differences between stateless HTTP and a old school client server architecture... well, there aren't any now. All the managers who want web apps to be just like their desktop will have a demonstration that it can be.
I foresee new frontiers in hacking based on vulnerabilities in the Java script engine though...
posted by i_am_joe's_spleen at 11:44 AM on February 21, 2005
It's also going to be demanded, absolutely demanded by all the management types. I've lost count of the patient explanations I've had to give of the web model, the need to post back to the server, the differences between stateless HTTP and a old school client server architecture... well, there aren't any now. All the managers who want web apps to be just like their desktop will have a demonstration that it can be.
I foresee new frontiers in hacking based on vulnerabilities in the Java script engine though...
posted by i_am_joe's_spleen at 11:44 AM on February 21, 2005
The only reason to aggressively pursue this technology now, as opposed to 2-3 years ago when it was first introduced, is that we're finally in an IE 6/Firefox/Safari world, rather than an IE 5/6/Netscape 4/6 world.
Indeed. I was doing remote scripting stuff in IE back in the 20th C. It was great for IE-only intranets, but once you got stuck on a "must work in Netscrape" job it went right out the door.
nixerman: I fear you do not understand the Web. This is very much in the spirit of asynchronous , URL/message-based computing.
i_am_joe's_spleen : Micorsoft has very nice, free script debuggering tools. But, yeah, Firefox with JavaScript console and such is uber sweet.
posted by Ayn Marx at 12:57 PM on February 21, 2005
Indeed. I was doing remote scripting stuff in IE back in the 20th C. It was great for IE-only intranets, but once you got stuck on a "must work in Netscrape" job it went right out the door.
nixerman: I fear you do not understand the Web. This is very much in the spirit of asynchronous , URL/message-based computing.
i_am_joe's_spleen : Micorsoft has very nice, free script debuggering tools. But, yeah, Firefox with JavaScript console and such is uber sweet.
posted by Ayn Marx at 12:57 PM on February 21, 2005
My prediction is that this will end up hugely favouring Mozilla.
I think Mozilla is already very popular within the web application development community. I don't see how this will make Mozilla more attractive for end-users, though.
It's also going to be demanded, absolutely demanded by all the management types.
It's been my experience that the exact opposite has been true until now. We've been building these sorts of applications for many years, and the people who've typically been interested in this sort of functionality have been end-users rather than managers. Managers are perfectly happy to pay less for less-usable applications because they don't account for productivity gains to be had from better interfaces. Perhaps this will change now that these managers can see viable public applications that use these mechanisms, but we'll have to wait and see.
I foresee new frontiers in hacking based on vulnerabilities in the Java script engine though...
The server-side part of the application need not be any more vulnerable than before.
nixerman: I fear you do not understand the Web. This is very much in the spirit of asynchronous , URL/message-based computing.
Since when has the web been about asynchronous, message-based computing? Building web applications that maintain client-side state, whether you use hidden frames or XMLHttpRequest or Flash interfaces, breaks the document-centric model of the web. Personally, I think that's a good thing, but I would disagree with your assessment of nixerman's understanding of the web.
posted by me & my monkey at 1:09 PM on February 21, 2005
I think Mozilla is already very popular within the web application development community. I don't see how this will make Mozilla more attractive for end-users, though.
It's also going to be demanded, absolutely demanded by all the management types.
It's been my experience that the exact opposite has been true until now. We've been building these sorts of applications for many years, and the people who've typically been interested in this sort of functionality have been end-users rather than managers. Managers are perfectly happy to pay less for less-usable applications because they don't account for productivity gains to be had from better interfaces. Perhaps this will change now that these managers can see viable public applications that use these mechanisms, but we'll have to wait and see.
I foresee new frontiers in hacking based on vulnerabilities in the Java script engine though...
The server-side part of the application need not be any more vulnerable than before.
nixerman: I fear you do not understand the Web. This is very much in the spirit of asynchronous , URL/message-based computing.
Since when has the web been about asynchronous, message-based computing? Building web applications that maintain client-side state, whether you use hidden frames or XMLHttpRequest or Flash interfaces, breaks the document-centric model of the web. Personally, I think that's a good thing, but I would disagree with your assessment of nixerman's understanding of the web.
posted by me & my monkey at 1:09 PM on February 21, 2005
My prediction is that this will end up hugely favouring Mozilla. I'm doing a lot of work on an intranet application using exactly this model (and it was written in late 2002). A good Javascript debugger is critical once you start doing this kind of thing in the client, and my word, IE is a pain in the arse in this department. if (debug) alert("got to line 145!") everywhere...Debuggers are important and while Ff's is nice (and handy) there certainly are similar items available for IE. That being this stuff is pretty neat but it's pretty new to me. I hadn't touched and dHTML/client side scriptinh in years before tackling a recent project and I'm sure that there are probably better tools available.
posted by mce at 1:16 PM on February 21, 2005
I first did this sort of thing in 1998 using JavaScript and a hidden frame to act as the transport mechanism.
posted by Captain Ligntning at 1:40 PM on February 21, 2005
posted by Captain Ligntning at 1:40 PM on February 21, 2005
The bookmarklet version of the JavaScript shell is insanely useful for this kind of programming and lets you run JS code in the namespace of the current document.
posted by thebabelfish at 2:19 PM on February 21, 2005
posted by thebabelfish at 2:19 PM on February 21, 2005
I first did this back in 1964, in pure machine code. But, of course, my credits get stolen.
posted by graventy at 2:20 PM on February 21, 2005
posted by graventy at 2:20 PM on February 21, 2005
Yeah, and you ripped off most of it from me. And I stole it from Turing.
posted by yerfatma at 4:04 PM on February 21, 2005
posted by yerfatma at 4:04 PM on February 21, 2005
For the record, I first coded a dynamic XML based menu using the XHTTPRequest back in 2001. And by "coded", I mean stole the code from the "Microsoft online MSDN library menu". It's funny however everyone is chowing down on Google's cock over Suggests and Maps, yet nobody got excited when MS used the technique 4 years ago.
I've used a similar technique in my web app since then (using IFrames rather the XMLHTTP thing), and while it is cool and can be a serious bandwidth saver at times, its use is limited if you don't have a shit hot collection of servers backing it up, as others have pointed out. In fact, if you don't have said servers, it is just as likely to make the app look slow and unresponsive.
posted by chill at 4:09 PM on February 21, 2005
I've used a similar technique in my web app since then (using IFrames rather the XMLHTTP thing), and while it is cool and can be a serious bandwidth saver at times, its use is limited if you don't have a shit hot collection of servers backing it up, as others have pointed out. In fact, if you don't have said servers, it is just as likely to make the app look slow and unresponsive.
posted by chill at 4:09 PM on February 21, 2005
I'm just in awe of JJG--wow.
posted by ParisParamus at 4:14 PM on February 21, 2005
posted by ParisParamus at 4:14 PM on February 21, 2005
Yeah! more javascript bugs to cause confusion.
When I run Firefox on XP, I often have 25 seperate windows of it, each with about 10 tabs. (i.e. 250 total tabs).
If one tab has javascript code that goes into an infinite loop, the only way to tell where the problem is, is to start closing tabs until the load average goes down.
I run the XP Task Manager all the time. I used to be able to catch initial problems by noticing the little Task Manager display go solid green. Now that I am donating my spare cycles to World Community Grid, the little display is solid green all the time and I get no early hint that something is wrong.
posted by MonkeySaltedNuts at 5:28 PM on February 21, 2005
When I run Firefox on XP, I often have 25 seperate windows of it, each with about 10 tabs. (i.e. 250 total tabs).
If one tab has javascript code that goes into an infinite loop, the only way to tell where the problem is, is to start closing tabs until the load average goes down.
I run the XP Task Manager all the time. I used to be able to catch initial problems by noticing the little Task Manager display go solid green. Now that I am donating my spare cycles to World Community Grid, the little display is solid green all the time and I get no early hint that something is wrong.
posted by MonkeySaltedNuts at 5:28 PM on February 21, 2005
Taken by itself, not a bad essay: readable, informative. But man, that's a big author photo.
posted by gimonca at 7:31 PM on February 21, 2005
posted by gimonca at 7:31 PM on February 21, 2005
Taken by itself, not a bad essay: readable, informative. But man, that's a big author photo.
yes. jjg is much smaller in real life.
posted by antimagnet at 8:09 PM on February 21, 2005
yes. jjg is much smaller in real life.
posted by antimagnet at 8:09 PM on February 21, 2005
« Older Paris; | Artificial Intelligence Newer »
This thread has been archived and is closed to new comments
posted by alana at 9:05 AM on February 21, 2005