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

[tye]

It has remained unapplied, because it is belived that it would cause increased (db) server load. (I can find no purticular reason for this belief, in fact, it should reduce the new-reply path by one getNode call, IIRC.)

Wow. You have a patch that will allow any number of users to request notifications for a node (by putting data into the database via a web page that will read hundreds of records from a database), and then it sends notifications to all of these users (by inserting a /msg record into the database for each such user -- unless you aren't using the current /msg system) and all with less work than is currently done (to send at most one message)? That is just amazing.

Of course, it isn't true.

In fact, your change would cause the entire list of people interested in a node to be read every time the node is displayed (and, with the current node cache, the list would have to be rewritten every time the node changed, including every time someone votes on it). So the increased load isn't just when people "subscribe" and when people reply, but every time a node is displayed. I don't know how much of an increase it is, but with a system that is (once again) out of DB server headroom, I am very reluctant to apply patches that cause the DB load to increase even a little.

And you should be careful about putting words into others' mouths. The increased server load is a small part of why I haven't applied that patch (I can't speak for why any other gods haven't, or if any have looked at it).

Then there is the issue of many people probably wanting to track a thread or a subthread rather than single nodes. Then there will be the requests for "which nodes am I currently tracking" which, with your design, would require scanning the entire node base.

Then there is the problem that it would change "/msg me when I get a reply" to be "/msg me if I get a reply to a node that I wrote while I had this setting turned on". And I'd rather avoid the use of "maintenance" nodes.

etc.

I think these problems are pretty good reasons for me not having put those patches high enough on my to-do list to get around to applying them yet.

The only plan I've heard that I consider viable at this point is: Do this external to PM (but please be very mindful of making efficient use of the server resources when you automate any use of PM). I suggested this a long time ago but I have yet to hear of anyone implementing it, so I don't feel particularly guilty for not having spent time trying to implement it inside of PM (such as by analyzing your patches, trying to come up with a better design, etc.).

                - tye

[PodMaster]

The only plan I've heard that I consider viable at this point is: Do this external to PM (but please be very mindful of making efficient use of the server resources when you automate any use of PM). I suggested this a long time ago but I have yet to hear of anyone implementing it, so I don't feel particularly guilty for not having spent time trying to implement it inside of PM (such as by analyzing your patches, trying to come up with a better design, etc.).

I don't know if you heard of it, but it did happened once (announcment here). Here's the quote from crazyinsomniacs homenode explaining how it disappeared

Damn, I still always confuse davorg with mirod when remembering things mirod says I think it was called the perlmonks threaded interface or something, but it was a CGI thingie, so even if you used it the script was on my machine. I tried using Google but I can't find it I'll try to rewrite it
mirod says no, I have lost everything in the crash (and I feel so dumb for it :--( I could try rewriting it though, I am away from home and I have a little time locked in my hotel room this week

You may remember that jcwren came up with Perlmonks Threaded Article Viewer which was ultimetely supposed to allow subscriptions.

Also, there was xNN and bivnn.cgi -- an alternate interface to newest nodes.

All the elements are there, somebody just needs to step up and write this thing, and i'm fairly confident that if somebody did that, jcwren or blakem would be gracious enough to host it (i hope).

Perhaps another Quest is in order? (motivation)

PS -- I love you man ;) (if i was real interested, I would have wrote it myself already).

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.

[dragonchild]

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
  

  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.

[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

[zby]

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.