|P is for Practical|
This is nice. Thank you very much. When I was working on this externally before, there were a few issues holding me up.
The first is that my implementation took the wrong approach. No work would be done unless the user "checked in" to see what nodes had been updated. After tye kindly pointed out the error of my ways, I started to re-implement but lost momentum for some of the other reasons.
The second was that I also wanted to include the ability to tell when a node's content had changed as well as if a new node had been added. While there is a flag in XML view that may be used, it currently isn't useful. If I understood tye just now in the CB, this will be possible when the new node cache is in production.
The third was that I was trying to be really resource friendly to PM. I don't think I knew about the XML Node Thread generator at the time. If I had, I could have easily performed the work off-site. Even then, watching a thread rooted at node X is still not straight-forward. How have you done it? Update: If I have understood the CB conversation correctly, you are only monitoring direct replies and not any indirect replies below a specific node.
Finally, I only had a year of perl under my belt and was working alone as a non-devil. If I remember correctly, I generated HTML using CGI rather than a templating framework. After feedback from tye on a few things I could have done a much better job but it was unrealistic of me to expect him to coach me through the entire process so I abandoned it.
That was 4 years ago. Thank you so much for taking this on and I hope very much the items on your todo list along with the content update gets included too. If you aren't also monitoring a thread rooted at node X, that would be great too.
Cheers - L~R