I don't really see how this fits the request. It lets you add (and delete) nodes to be tracked and list nodes that are being tracked, but the only way (as far as I can tell) to check if a "tracked" node has changed is to cycle through the nodes one at a time (and I don't see an interface to make that possible without me retyping each node ID).

I thought the point of building a list of nodes to be tracked was so that one could be told "here are the new replies to any of your tracked nodes" (either with one page load or via notifications sent out by some cron job).

Using your current technique of grabbing information, adding such a feature would not be an efficient use of the server. It would refetch the entire thread list for each interesting thread (and fetch that separately for each user who wants to track the same thread) every time someone wants to check.

To do something like this efficiently, you'd want to use the newest nodes ticker to fetch info about any new nodes since the last time you checked for updates (and not per user). If it becomes popular, then you'd want to not try to fetch info about new nodes if you just did that a short time ago.

tye,
Thank you for your comments.

I thought the point of building a list of nodes to be tracked was so that one could be told "here are the new replies to any of your tracked nodes" (either with one page load or via notifications sent out by some cron job).

It's possible. This requires 1 call to the XML Node Thread ticker for each thread being tracked, but only a single a single call to the node query XML generator. The sorting out of what node belongs in what thread would be done on the external server. The only way I can think to limit the impact is restrict the number of nodes that can be tracked at any one time.

Using your current technique of grabbing information, adding such a feature would not be an efficient use of the server. It would refetch the entire thread list for each interesting thread (and fetch that separately for each user who wants to track the same thread) every time someone wants to check.

I guess my vision of using this tool is slightly different. Users that didn't login for weeks could still see if there were any updates to nodes long gone from Newest Nodes. Since there is not a constant check for updates, the only time the time PerlMonks gets queried is if the user runs a report. I also envisioned different users tracking nodes at different rates.

Cheers - L~R

tye,
After our recent CB conversation and a modification to one of the XML tickers, I believe I can do better. I will start on this soon. Before I announce publicly I would like you to review it, if you don't mind?

Cheers - L~R

Also, kindly involve cookies in the picture because there's no point in logging in every time someone wants to add a node for tracking.

See this for a good cookie loop ;)

MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"

I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).

** The third rule of perl club is a statement of fact: pod is sexy.

and the readme:

Cheers - L~R