As you noted, dsHistory acts more like an “undo” / “redo” enabler. Unlike RSH, dsHistory generally can’t keep up with the back / forward buttons after a user has gone on to another page and subsequently back to the dsHistory-enabled page. If the user _did_ end up arriving at the dsHistory-enabled page via the back button after having moved on, it’s definitely possible that they could have a bad user experience if they continued to use the back button after reaching the page again. To me, this limitation just means that dsHistory will never be the right choice for every app and set of circumstances / requirements.

That said, I’ve really enjoyed working on dsHistory; it has certainly presented some unique development challenges that I hadn’t encountered elsewhere. I studied RSH quite a bit before I initially built dsHistory back in Apr ‘07, and I’ve been looking over your recent work to get some idea on how I can implement support for Safari 2 and Opera in my own library. It seems like it’s going to be a lot of work, but I’m really grateful that I don’t have to start from scratch like you did!

Have you considered creating unit tests for RSH? The complexities I encountered while developing dsHistory make it really hard to ensure bug-free functionality across all browsers, so it’s an absolute requirement for me to finish some unit tests for cross-browser functionality before I reach v1.0. I’ve narrowed my choices down to Selenium ( http://selenium.openqa.org/ ) and JsUnit ( http://www.jsunit.net/ ), but I was just curious to see if it was something you had considered or done research on.

Anyway, thanks again for the writeup and compliments.