I hate to say it, but I no longer have time to keep up with the bugs, requests and upgrades for Subscriptions. If anyone is interested in taking over, please let me know. Thanks, -- Dan Ziemecki
As the new-ish maintainer for Notify module I'd definitely like to have one solid subscription module (or, probably better a SubscribeAPI module...calling all Eatons :-) ) to avoid all this duplication (notify, subscription, subscriptions, et al). This has been a desire of mine for a while, but lack of time has hampered that. Once Drupal 5 is out, I'm going to be porting Notify and will look into refactoring the code to properly implement a SubscribeAPI module so other modules can subscribe to... 1. nodes (i.e. by nid [say, for project issues], tid [forums], View [all new/update nodes in a particular view], uid [all Joe's content], type, etc.), 2. comments, 3. taxonomy (i.e. newly added tags), 4. users (i.e. new user registrations). But I'd like (and need) some help just with the initial direction from some big boys so this can get done right for D5/D6 as I'm not as great of a visionary as some on this list. Recently on the list there was talk of a relationships API and I feel that SubscribeAPI could benefit from something similar so that we could have one table showing relationships between a subscriber uid and another node/node type/comment/vocabulary/term/view/uid/etc. Thoughts? Rob Roy Barreca Founder and COO Electronic Insight Corporation http://www.electronicinsight.com rob@electronicinsight.com Dan Ziemecki wrote:
I hate to say it, but I no longer have time to keep up with the bugs, requests and upgrades for Subscriptions. If anyone is interested in taking over, please let me know.
Thanks, -- Dan Ziemecki
Rob Barreca wrote:
As the new-ish maintainer for Notify module I'd definitely like to have one solid subscription module (or, probably better a SubscribeAPI module...calling all Eatons :-) ) to avoid all this duplication (notify, subscription, subscriptions, et al).
This has been a desire of mine for a while, but lack of time has hampered that. Once Drupal 5 is out, I'm going to be porting Notify and will look into refactoring the code to properly implement a SubscribeAPI module so other modules can subscribe to...
1. nodes (i.e. by nid [say, for project issues], tid [forums], View [all new/update nodes in a particular view], uid [all Joe's content], type, etc.), 2. comments, 3. taxonomy (i.e. newly added tags), 4. users (i.e. new user registrations).
But I'd like (and need) some help just with the initial direction from some big boys so this can get done right for D5/D6 as I'm not as great of a visionary as some on this list.
Recently on the list there was talk of a relationships API and I feel that SubscribeAPI could benefit from something similar so that we could have one table showing relationships between a subscriber uid and another node/node type/comment/vocabulary/term/view/uid/etc.
Just to throw another monkey into the works, the views scheduler module should be capable of notifications as well, when set up properly.
Just to throw another monkey into the works, the views scheduler module should be capable of notifications as well, when set up properly.
Oh, nice. So, a majority of content subscriptions could be done this way: using Views Scheduler, along with Actions, Schedule (haven't checked this out yet), Views to create subscriptions of content. Then, we'd want another module to allow single subscriptions to single nodes, like for project issues so we could have a "(un)subscribe to this %type" link for nodes. Then, another module to subscribe to new user registrations (think there is an existing module that does this), etc. So I suppose Actions (maybe Schedule too) would play a big role in a SubscribeAPI module. Rob Roy Barreca Founder and COO Electronic Insight Corporation http://www.electronicinsight.com rob@electronicinsight.com Earl Miles wrote:
Rob Barreca wrote:
As the new-ish maintainer for Notify module I'd definitely like to have one solid subscription module (or, probably better a SubscribeAPI module...calling all Eatons :-) ) to avoid all this duplication (notify, subscription, subscriptions, et al).
This has been a desire of mine for a while, but lack of time has hampered that. Once Drupal 5 is out, I'm going to be porting Notify and will look into refactoring the code to properly implement a SubscribeAPI module so other modules can subscribe to...
1. nodes (i.e. by nid [say, for project issues], tid [forums], View [all new/update nodes in a particular view], uid [all Joe's content], type, etc.), 2. comments, 3. taxonomy (i.e. newly added tags), 4. users (i.e. new user registrations).
But I'd like (and need) some help just with the initial direction from some big boys so this can get done right for D5/D6 as I'm not as great of a visionary as some on this list.
Recently on the list there was talk of a relationships API and I feel that SubscribeAPI could benefit from something similar so that we could have one table showing relationships between a subscriber uid and another node/node type/comment/vocabulary/term/view/uid/etc.
Just to throw another monkey into the works, the views scheduler module should be capable of notifications as well, when set up properly.
Rob Barreca wrote:
Just to throw another monkey into the works, the views scheduler module should be capable of notifications as well, when set up properly.
Oh, nice. So, a majority of content subscriptions could be done this way: using Views Scheduler, along with Actions, Schedule (haven't checked this out yet), Views to create subscriptions of content.
Then, we'd want another module to allow single subscriptions to single nodes, like for project issues so we could have a "(un)subscribe to this %type" link for nodes.
Then, another module to subscribe to new user registrations (think there is an existing module that does this), etc.
So I suppose Actions (maybe Schedule too) would play a big role in a SubscribeAPI module.
Theoretically you could use something like views bookmark and subscribe to a view that includes your bookmarked nodes. With current views you could probably get comments and nodes (though you'd need 2 different views).
This has been a desire of mine for a while, but lack of time has hampered that. Once Drupal 5 is out, I'm going to be porting Notify and will look into refactoring the code to properly implement a SubscribeAPI module so other modules can subscribe to...
thats what subscription.module does - and in my opinion, it ended up being overengineered IMO. i'm not so sure that this API is a fruitful path. i'd be happy to be proved wrong though.
On 20 Nov 2006, at 20:18, Dan Ziemecki wrote:
I hate to say it, but I no longer have time to keep up with the bugs, requests and upgrades for Subscriptions. If anyone is interested in taking over, please let me know.
For what it is worth, I'd like to have a _basic_ subscription module in core. I'm not interested in a 'subscribe to the world'-style subscription module, but in simple things like providing notification of new comments. KISS. -- Dries Buytaert :: http://www.buytaert.net/
On Thursday 23 November 2006 02:36, Dries Buytaert wrote:
On 20 Nov 2006, at 20:18, Dan Ziemecki wrote:
I hate to say it, but I no longer have time to keep up with the bugs, requests and upgrades for Subscriptions. If anyone is interested in taking over, please let me know.
For what it is worth, I'd like to have a _basic_ subscription module in core. I'm not interested in a 'subscribe to the world'-style subscription module, but in simple things like providing notification of new comments. KISS.
Dan is handing over the ropes for the subscriptions module to me and I'd welcome other feed back like this. Once I get the 5.0 version of the module out and sort though the issue que, this is a potential issue that I'd like to address. If people would like to help sort out what a minimal spec might be, I'll try to organize it and make it a priority. best, arthur
-- Dries Buytaert :: http://www.buytaert.net/
-- arthur@civications.com
participants (6)
-
arthur -
Dan Ziemecki -
Dries Buytaert -
Earl Miles -
Moshe Weitzman -
Rob Barreca