Re: Re^2: RFC: Subscription to nodes (really?)

I haven't looked at a line of the PM code, so please tell me to shut up when I go out of line.

Let's change subscription to watching. What about the following design:

Every node knows about its parent.
Every node would have a list of watchers associated with it. This list would be taken from the Personal Nodelet of each Monk.
If a reply is made to a node, all watchers would have their personal nodelet updated to have an asterisk (or similar notification) put to it. Basically, a flag would be set in the Personal Nodelet table for each monk.
The watching of a post and its descendents would be implemented by having a user be a watcher on every single post. And, when a reply is made, that monk would become a watcher on the new post automagically. The trick is to make sure that the right spot in the Personal Nodelet is updated.
So, you could do the following table:
```
Thread_Watching
---------------
Node_Id
Monk_Id
Nodelet_Id
[download]
```
And, if a reply is made to that node, then that Nodelet_Id is updated. If the Node_Id != the Nodelet_Id, then the monk must be watching the whole thread, so add that monk to the new node's Thread_Watching entries.

I have no idea how much work that would take, and I can't provide a huge amount of coding help (4 kids), but I'll help as much as I can ...

------
We are the carpenters and bricklayers of the Information Age.

The idea is a little like C++ templates, except not quite so brain-meltingly complicated. -- TheDamian, Exegesis 6

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

Comment on Re: Re^2: RFC: Subscription to nodes (really?) Download Code

Replies are listed 'Best First'.
Re^4: RFC: Subscription to nodes (design) by tye (Sage) on Sep 23, 2003 at 15:28 UTC
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	[reply]
Re: Re^4: RFC: Subscription to nodes (design) by zby (Vicar) on Sep 23, 2003 at 16:19 UTC
Nice to see that my idea from Re: Re^3: A feature for Personal Nodelet (nightmare) was not forgot. There is one minor problem with it, that I see now, - some people use PM not allways with the same brawser and this wan't be consistant when people will change brawsers.	[reply]