subscriptions and subscriptions_ui modules have been tested a bit, the subscriptions_mail has not been tested (there is not an even info yet). There will be an upgrade path and proper install. Install, index and other coming. Run this MySQL to test with UID 1.

CREATE TABLE subscriptions (module varchar(255) default '' NOT NULL, field varchar(255) default '' NOT NULL, value varchar(255) default '' NOT NULL, recipient_uid int(11) default 0 NOT NULL, send_interval int(11) default 0 NOT NULL, author int(11) default 0 NOT NULL);
CREATE TABLE subscriptions_queue (uid int(11) default 0 NOT NULL, name varchar(255) default '' NOT NULL, mail varchar(255) default '' NOT NULL, language varchar(255) default '' NOT NULL, module varchar(255) default '' NOT NULL, field varchar(255) default '' NOT NULL, value varchar(255) default '' NOT NULL, author int(11) default 0 NOT NULL, send_interval int(11) default 0 NOT NULL, digest int(11) default 0 NOT NULL);
CREATE TABLE subscriptions_user_settings (uid int(11) default NOT NULL, digest int(11) default NOT NULL);
INSERT INTO subscriptions_user_settings VALUES (1,0);

Immediate sending is gone it's a bigger PITA than it's worth.

Our goals here are code cleanliness, expandability and real scalability. None of them were prelevant. Currently you can subscribe with the new UI and the moduel will queue. Send not yet it's being heavily worked on. Sorry for the many delays but I wasted a lot of time trying to fix the old codebase.

CommentFileSizeAuthor
#2 subscriptions_ui.module.txt2.98 KBchx
subscriptions_new.tgz9.72 KBchx

Comments

firebus’s picture

firebus commented

subscribing.

chx’s picture

chx commented
StatusFileSize
new subscriptions_ui.module.txt2.98 KB

Today was day off. I made some small fixes, though. There is a try to keep a default value in _ui. The module will need some more love because currently it queues your subscription instead of the object that matched it. More to come.

jose reyero’s picture

jose reyero commented

subscribing

chx’s picture

chx commented

The adventure continues at https://4si.devguard.com/svn/public/ , check it out. Yes, it sends mails. No it does not come with an install, sorry. Yes, it's insanely powerful because now it queues the object in question represented by its load function and load arguments. No, comments is not right, but that's an easy fix.

chx’s picture

chx commented

i dumped my subs tables in a mysql.

pukku’s picture

pukku commented

Is there any way to bring back immediate sending? This was one of the key functions that we wanted from a subscriptions module.

introfini’s picture

introfini commented

subscribing

salvis’s picture

salvis
he/his
commented

Immediate sending was important for me, too, and chx tried to make it work, but it's a pain, especially when you add in access control modules. It's also a pain to maintain two different code paths — for long-term stability, it makes sense to concentrate on the one that scales well.

If you control your host, you can set cron to run as often as you like, and you should be able to get pretty close to immediate sending, and at the same time enable your users to select their preferred delivery schedule.

Even if we'll only have the cron mechanism in the future, sending (a bunch of) single messages will continue to be an option.

chx’s picture

chx commented

So currently the model is this: subscriptions module queues and the subscriptions_mail takes a number of items off the queue and sends them. It should not be a problem to add a hook_exit implementation to somewhere which would invoke subscriptions_mail_cron -- that's one line of code. Despite it sounds easy it would make the module a bootstrap module which is a performance burden and also it's actually reimplementing poormanscron so I am not fond of the idea. Why do you need immediate, what's there that cron/poormanscron can't do?

jose reyero’s picture

jose reyero commented

The issue with inmediate sending is that it just doesn't scale beyond some point. For some number of users/subscriptions you cant just send all the messages out in a single page request.

I don't see it has any advantage over just sending stuff out in cron a few minutes later. Just for the case when you cannot/dont want to set up cron, poormanscron will do just the same work, plus it will scale if we build some powerful cron handling and maybe will send all the messages in a pair crons.

One more option: some pluggable module that will just run cron each time a subscription is triggered. It should be like a custom version of poormanscron.

So we should really focus in keeping the base framework simple, forget about inmediate sending built in -the options above will do- and build some really scalable queue processing.

firebus’s picture

firebus commented

i've found, with the current subscriptions module, that cron send doesn't scale very well either. at a certain (high) level of activity, the holding table gets too big to be processed in one cron.

i've improved that on my site by having subscriptions_cron respect the search_cron_limit variable and only process that many each run.

gustav’s picture

gustav commented

I am glad I found this post. Is there any reason why the development is not taking place in the drupal cvs? That would make it easier for people to find it and test it.

salvis’s picture

salvis
he/his
commented

It's not ready for testing yet.

Be assured that we are as eager to post a beta (alpha?) version as you are to see it.

zephyr325’s picture

zephyr325 commented

Subscribing! Woot!

salvis’s picture

salvis
he/his
commented
Status: Needs work » Fixed

We're happy to have a first BETA version of the new Subscriptions 2.0 out!

If you'd like to take a first look and help with testing, then get it from the link on http://drupal.org/project/subscriptions, but do heed the warnings!

Please open new issues for feedback about the new version 2.0!

salvis’s picture

salvis
he/his
commented
Anonymous’s picture

(not verified) commented
Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.