dshistory destroys window hash

[Kekoa]

I am using dshistory to manage history but have needed to supply my
own hash encoding and decoding for more simple urls that don't confuse
users. However, when i set the location.hash, it seems dshistory
comes in and urlencodes it for you. I don't think this is a
particularly useful feature, or at least should be able to be
disabled. (I just changed the getEncodedWindowHash() method to return
the original hash, removing all other code in the method as I never
use it.

How actively is this being developed? I can see a real use for some
changes here and making a history library that is a bit more flexible.

For the most part I like the project and the niche of services it
provides an Ajax enabled site. I have run into a few issues, and have
learned more about what's in dshistory by stepping through code.

I think the code can be particularly more useful if it would emit
events(by allowing people to register handlers) to perform work(such
as encoding/decoding a hash) to make the framework more flexible. If
anyone has interest I would be willing to chip in on periodic
developments to this library.

[Andrew Mattie]

dsHistory is still very much alive. I haven't had as much time to work on it in the past month as I would have liked due to a side job that has taken up a lot of my time, but keeping the project up-to-date is still very much an important priority to me. In fact, I just made a svn commit earlier today to fix a bug that's been affecting a number of users.

Regarding the encoding of the window hash that you spoke of, the encoding / decoding of the hash keys and values was added as a bug fix. Prior to the addition of the encoding / decoding, the addition of a key / value pair like "my key #1" / "value #1" would cause cross-browser issues when trying to evaluate the length of those strings directly from the hash. Subsequently acting on that evaluation when updating value or removing the pair altogether caused some bugs that were very hard to track down. I suspect you'll have the same issues if you extensively test different key / value combinations in different browsers.

Before dsHistory 1.0 is released, I want to finish my unit tests for dsHistory and make sure everything works in the (currently) supported browsers. After that, I am going to look forward to better browser support for v1.1, possible window title updating support for v1.2, and possible support for Safari 2.x somewhere within there. I realize that posting a non-descriptive timeline like that in the Groups isn't the greatest reassurance in the world that dsHistory is being worked on, but until I can get time to finish my unit tests, that's all I have to give at the moment.