I'd like to be able to be able to mark a node such that whenever it changes or a reply is posted to it, I will receive a message. In addition, it would be neat if I could indicate this node only or this node and all descendents.
Essentially, the messages one receives when a response is posted to a node one wrote would be an automatic subscription to all of your own nodes.
Reason: There are a lot of questions asked that I would love to follow, but I don't want to wade through 500 responses every morning. I just want to know that a given thread has new posts in it.
------ 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.
Re: RFC: Subscription to nodes
by theorbtwo (Prior) on Sep 22, 2003 at 20:52 UTC
|
This has come up many times before, in various forms. Varying is if notifications happen only on reply, or also on edit/update, if they apply recursivly (that is, to decendents of the nodes being watched), and how notifications come in (via a * next to the node on the personal nodelet, via /msg from root, or via email).
A limited form of this is actualy already here. A user can subscribe /msgs for direct replies on all nodes belonging to them. This, however, is all-or-nothing, and only for nodes authored by the person attempting to watch them. This makes it of limited use.
I've actualy written code that implements more or less this. (Specificly, only direct replies, but for any node, and for any user, on a one-at-a-time basis.) 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.)
Warning: Unless otherwise stated, code is untested. Do not use without understanding. Code is posted in the hopes it is useful, but without warranty. All copyrights are relinquished into the public domain unless otherwise stated. I am not an angel. I am capable of error, and err on a fairly regular basis. If I made a mistake, please let me know (such as by replying to this node).
| [reply] [Watch: Dir/Any] |
|
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
| [reply] [Watch: Dir/Any] |
|
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. |
| [reply] [Watch: Dir/Any] |
|
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:
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.
| [reply] [Watch: Dir/Any] [d/l] |
|
|
Re: RFC: Subscription to nodes
by mpeppler (Vicar) on Sep 22, 2003 at 17:53 UTC
|
I'll second that request - I would find that incredibly useful as well!
Michael
| [reply] [Watch: Dir/Any] |
Re: RFC: Subscription to nodes
by zby (Vicar) on Sep 22, 2003 at 19:15 UTC
|
| [reply] [Watch: Dir/Any] |
Re: RFC: Subscription to nodes
by Popcorn Dave (Abbot) on Sep 22, 2003 at 19:15 UTC
|
| [reply] [Watch: Dir/Any] |
Re: RFC: Subscription to nodes
by valdez (Monsignor) on Sep 22, 2003 at 23:54 UTC
|
Subscription to nodes would be really nice, it has been discussed many times in the past, if i recall correctly. I don't know if someone will ever produce the code for this feature, but you already have all the tools you need to build your own subscription service, why don't you try to write it? You could start from newest nodes xml generator... Oh, don't forget to take a look at grinder's Moz Sidebar!
Besos from Merida, Valerio
| [reply] [Watch: Dir/Any] |
Re: RFC: Subscription to nodes
by DrHyde (Prior) on Sep 22, 2003 at 19:31 UTC
|
I haven't looked at the code, but this would probably be quite complex.
Simpler, I'm sure, would be to send me email when someone replies to one of my nodes. It would, I expect, scratch most of the itch here. | [reply] [Watch: Dir/Any] |
|
| [reply] [Watch: Dir/Any] [d/l] |
|
Furthermore, I want to be notified if a given thread has updates. There are several wonderful topics that I may or may not have posted in, but I would love to follow. PM should make the hard things easy. :-)
------ 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.
| [reply] [Watch: Dir/Any] |
|
| [reply] [Watch: Dir/Any] |
|
| [reply] [Watch: Dir/Any] |
Re: RFC: Subscription to nodes
by Abigail-II (Bishop) on Sep 22, 2003 at 20:25 UTC
|
Reason: There are a lot of questions asked that I would love to follow, but I don't want to wade through 500 responses every morning. I just want to know that a given thread has new posts in it.
This, and a lot more of similar requests, could be
solved by adding an NNTP gateway. With many news clients,
requests like yours can be done easily.
Abigail
| [reply] [Watch: Dir/Any] |
|
If we follow that direction why not just create comp.perl.perlmonks? Because, of course, it wouldn't have nearly the same community feel. No chatterbox, no user homenodes, no pretty html and css ;-), and so forth. It would become just another newsgroup rather than the current excellent resource it is.
It's also only one feature we're talking about here. Hardly worth a major change in my opinion :).
| [reply] [Watch: Dir/Any] |
|
| [reply] [Watch: Dir/Any] [d/l] [select] |
|
Re: RFC: Subscription to nodes
by Roger (Parson) on Sep 23, 2003 at 07:30 UTC
|
Ummmm, isn't there a simpler solution already?
Say, the discussion node - Walks like a regex, quacks like a regex... has the following link:
http://www.perlmonks.com/index.pl?node_id=293374
Just add that (or any interesting nodes) to your Favorites folder on the browser, and check that later to see what's been posted?
Having said that, I think the subscription to a node idea is great. I will vote for that too. | [reply] [Watch: Dir/Any] [d/l] |
|
Although the Favourites folder would obviously do the trick on one level, it would mean checking each node manually on the off-chance there's been an answer. And Perl Monks being what it is there could be a reply of note a twelve month down the line or longer by which time presumably you've either hired staff to carry on checking your by now bloated favourites folder or you've simply stopped checking that node.
The subscription idea would certainly be a useful addition so I vote for that too...
| [reply] [Watch: Dir/Any] |
|
| [reply] [Watch: Dir/Any] |
|
Re: RFC: Subscription to nodes
by Limbic~Region (Chancellor) on Sep 23, 2003 at 17:51 UTC
|
dragonchild,
I am working on an external method of accomplishing this. Unfortunately it will be limited to only checking for new replies and not content change. This is because there is no easy way to tell if a node has been modified without getting a checksum of the node. That would require recursive processing and the benefit doesn't come close to added strain to the server. I am currently tracking this thread, so if it works, I will update in a little while with the very pre-alpha version.
Cheers - L~R
Update: here it is. | [reply] [Watch: Dir/Any] |
|
|