[development] subscribe to a node

[Bèr Kessels]

Hello

I think a general subscription framework may be the best Utopian solution. 
Or else some well thought out combination of modules (CCK + views + workflow + 
actions should offer it all), AND (in core) a *tiny*, specific subscription 
module, which solves only *one case* of subscription. 

Op dinsdag 31 oktober 2006 15:46, schreef Dries Buytaert:
> subscriptions.module

Basic review of subscriptions module

 * Subscriptions are hardwired to nodes and comments. This hardwire-mistake is 
made once with the file-handling framework architecture. Lets not go there 
again. 
 
 * Someone decided to hardwire 'blogs subscriptions'. This is far too 
specific.

 * user_mail is hardcoded into it. We all know this does not scale at all. The 
mailing engine should at least be pluggable. 

  * Mailing vars  (%tokens) are hardwired. If this is a general subscription 
system, that needs to be at least better configurable, but ideally the tokens 
alter-able by some hook(s).

  * Subscriptions offer no proper hookable points. Its either 'do as I say' or 
nothing. Ideally one can hook into various places in the subscription 
workflow and alter the send mails, alter who gets what etc. 

  * The UIs are all hardcoded into the system. It depends entirely on the 
case, what a good UI has/is and where it is. Some options I think of OOTMH
    * subscribe to all stuff from user X
    * subscribe to comments for node X
    * subscribe to revisions for node X (wiki) 
    * subscribe to a group of nodes (grouped by terms, tags, OGs, node types)
    * advanced subscriptions (where field F > X AND author.role in (admin, 
moderator)  etc) 

Some more technical "asides"
  IMO a cached menu with a path ''path' => "user/$user->uid/subscriptions"' is 
plain wrong. 

  "Unsubscribe from this node type. " We agreed never to use the word "node". 
And what the ** has a user/guest got to do with 'types'?

   Code style is very non-standard. It would need an almost 100% rewrite 
(style rewrite, notlogic) to be core-worthy.

   Code comments are inconsistent and need a big overhaul.

   I see a lot of fancy Superglobal usage and complex query-crafting. These 
are so fancy and so complex that after 15 minutes of staring, I can still not 
say if this is actually secure/safe. The fact one cannot review security 
well, itself, can be considered a security problem.

Bèr