Re^4: RFC: Subscription to nodes (design)

[tye]

Just FYI, the personal nodelet contents are part of your user settings, not a separate node.

I don't think any scheme that ends up multiplying (number of interested monks)*(number of interesting nodes) will be viable from within PM.

You did remind me of an idea that avoids many of the pitfalls. Have links in the personal nodelet (or scratchpad) include a ";replies=$N" and/or ";updated=$when" parameters so that your browser keeps track of whether you've seen the node since the last update (links change color if the node has been updated since you last read it). This means that new replies only have to update a single additional place (the root node -- because I'd only have this work for new nodes anywhere under a root node or for direct replies to other nodes, for the sake of server load) and the personal nodelet (or scratchpad) could be taught to get the information it needs efficiently. If we get the "last updated" field updating properly, then we could just use that and the information would be available without extra load (per personal nodelet link).

This would still add sever load, even if we just used "last updated" (which doesn't work yet), because it would encourage more links in the personal nodelet which means more DB reads for every page hit. Being able to quickly collapse/expand the personal nodelet (I know this works from user settings but I thought the idea was to have a link inside the nodelet that does the collapsing and I don't see one there) has the potential to reduce that problem (though I think many will have links in the personal nodelet that they always want access to).

So I'd much rather do this only in the scratchpad. (The more I think about this, the more I'm not willing to do it in a nodelet.)

I can't provide a huge amount of coding help (4 kids), but I'll help as much as I can

The problems with implementing something like this in PM is not really coding hours. We have a huge list of members in pmdev and even though most of them have not submitted more than a few patches, many of them have. There still aren't great ways to thoroughly test patches and the real bottleneck is getting patches approved/tested/applied, which is probably a big part of why more patches don't get submitted.

So (at the risk of repeating myself), if you want to offer some coding help, then help someone (re)write an external method of doing this.

BTW, what I'd like more than any of this (for the same purpose) is to have Newest Nodes separate "new replies to new threads" from "new replies to old threads".

                - tye