Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

RFC: Subscription to nodes

by dragonchild (Archbishop)
on Sep 22, 2003 at 17:17 UTC ( [id://293194]=monkdiscuss: print w/replies, xml ) Need Help??

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.

Replies are listed 'Best First'.
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).

      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
        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.

        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.

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

Re: RFC: Subscription to nodes
by zby (Vicar) on Sep 22, 2003 at 19:15 UTC
Re: RFC: Subscription to nodes
by Popcorn Dave (Abbot) on Sep 22, 2003 at 19:15 UTC
    Would it be possible to mirror the original node in question and if the page has changed, you'll know there are responses? Or would that put too much of a hurt on the server for multiple mirrorings?

    There is no emoticon for what I'm feeling now.

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

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.

      There is an option in User Settings, in the Miscellaneous section, to /msg me when there's a reply to one of my posts, which works well in notifying me of direct responses, but it doesn't tell me if someone responded to my responder with a correction.

      Knowing whether the whole thread has any updates is different from knowing if you've been responded to personally. We have an existing option for the later, but the former sounds quite handy. I can spend even more time at the Monastery. :)


      "No, no, you're not thinking, you're just being logical." - Niels Bohr
        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.

      I haven't looked at the code, but this would probably be quite complex.

      How do you figure that? Just add in an extra function call whenever a node is posted that checks who's monitoring the node's parents and send a message to those users. Seems straightforward to me :)

        Oh yes, look at the parent, get a list of interested people, then look at *its* parent, get a list of interested people, then *its* parent, and so on. Then de-dupe the list, then mail it out efficiently. That alone could get quite expensive.

        You also need a database schema change to somehow record a list of people who want to be mailed about posts. Plus the interface for users to add and remove themselves from those lists.

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

      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 :).

        I don't use the chatterbox; why should I? IRC has a much nicer interface. User homenodes isn't something I care about (after all, we do have the web already). As for HTML and such, I find it a blessing I can post plain text on Usenet; that on Usenet $a [1] only takes me 6 characters to type, and not the 19 of <code>$a [1]</code> I've to type here. This place doesn't even have the option of posting plain text, not even POD. (So much for a Perl site).

        It takes far less time to post on Usenet than to post here.

        Abigail

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.

      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...

        BTW, Mozilla (at least, 1.4) has a nice feature allowing to set a schedule for each bookmark to be checked for updates. I'm going to give a try to use it..

        --dda

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.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: monkdiscuss [id://293194]
Approved by mpeppler
Front-paged by gmax
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others cooling their heels in the Monastery: (7)
As of 2024-03-19 02:29 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found