I want to do something very similar to Google Doc\'s live updating - where all users can \"immediately\" see the actions of the other users in the doc.
To achieve this,
I recommend using a Comet framework like Atmosphere. It will automatically choose a transport mechanism for your messages, which can be websockets if you're lucky (but as this is abstracted away, you do not have to worry). Anyway it is great value if you do not have to deal with individual requests / responses and all the error sources and browser bugs that you will encounter. I've been there. There be dragons. :-)
If you don't want to use Web Sockets because they're not widely supported, you'll want to look up Comet. That's how Google Docs probably does it.
One way to limit the # of ajax requests is to get clever with spacing them out. You don't need to make a request every second. When you get a response with activity, then do another request in 1 second. If no activity, then 2 seconds, then 4, etc, with maximum of maybe 30 seconds in between requests. When updates happen, reset the timer. Basically, space your requests in a smart way to make the GUI look as responsive as possible.
I vote for Long-poll strategy : each client opens a request to the server, but the server never breaks up connections, and just send pieces of java-script from time to time.
Constant AJAX requests would kill your server.
If your users are only using modern browsers than i would try out the websocket standard coming with HTML 5. More and more browser will support it in the future and companies like Google and Apple are working on this. Here a getting started tutorial: http://net.tutsplus.com/tutorials/javascript-ajax/start-using-html5-websockets-today/
EtherPad has been open-sourced, if you're looking for a realtime collaborative rich text editor.