Hi Honza and all,
>> 4.2 Specification detail
>> Table subscriptions
>> uid CHAR(40) NOT NULL,
>> category VARCHAR(16),
>> content_type VARCHAR(20),
>> slice_owner VARCHAR(16) NOT NULL,
>> frequency SMALLINT NOT NULL,
>> last_post DATETIME DEFAULT '1980-01-01 00:00:00' NOT NULL,
>> INDEX uid(uid)
>> INDEX frequency(frequency)
> We can add one column subscription_type, which we can use in future for
> "new item notification", "new slice available notification" or for say SMS digest,
> which means format digest for mobil phones.
It would be good to include similar functionality in one spot, but I
must admit I see more differences in functionality here...
Email subscription for readers:
- the email subscription is not attached to a slice
- email is sent on cron events
Email slice event notification
- is bound to a single slice
- email is sent on user action events
> (It is better to modify the database structure in one step, because it allways
> needs accessing mysql administration (= extra step for AA administrators))
Now the draft spec for the notification service is finished, too, so
both changes might come at the same time. Anyway, maybe we could add
an automated procedure for table modifications? I just updated my test
installation to the current CVS version and I had to modify the items
table. Are there instructions somewhere on how to do a proper update?
For example, a file with ALTER TABLE statements could help. Or, in the
ideal case, AA scripts would realize the update themselves and change
the tables on their own.
>> Table categories
>> The existing table is to be modified. A field email_sub_usable should
>> be added:
>> email_sub_usable SMALLINT(5) DEFAULT '0'
> Yes, it is good.
> I think, I have solution of "liberty in categories names discussion":
> We can create common categories as "parents" of specific categories used
> in slice. Then, for example Carbusters, can use its categories "Trucks", "4x4",
> "Alternatives" in its slice, but the parent category for those categories will be
> the same - "Environment - Transport". The subscription then should be on
> common categories. Is it understable?
That's a really good idea I think. It would solve the category
problems altogether. It would, however, make some functions more
complex... category table and category administration would need some
modifications, and we will have to look over most code that uses
The real, "fine" categories would be used everywhere. Categories would
need to know which is their parent (extra field in database table,
extra administration page control(s) and logic).
The parent categories would be used in email subscription manipulation
and possibly in the slice directory (see "slice profile and
What do people think?
>> 5.2 Specification
>> php script which actually sends the digests: email-digest.php3
>> Create the email message text from the resulting records as described in the
>> requirements section of this paper
> We can use the came formating with aliases as we use in compact and
> fulltext view. The advantage is
> - tested and working mechanism
> - format can be specified on slice basis (not all slices will use description
> field, but in diggest we can use for example ISBN (in new books slice))
> The diggest format should be editable by superusers only.
Good point. There is one problem, though: Emails are created based on
n slices, not on 1. Which template should be used?
> >> 6.5 Specification: Automatic cleanup of automatically created user
>> accounts: email_auto_cleanup.php3
>> An automatically created user account is considered to be trash if
>> the account has not been confirmed 24 hours after creation
> Too short - one week will be better - not all users are on e-mail each day.
Right. Okay, to be changed.
>> 7. Subscription Manipulation
> Just a question. Do you think it is better to use this positive confirmation
> mechanism (you are subscribed after setting account and confirming) than the
> negative one (you are subcribed just after setting account). If we use the
> negative one, the first message to subcribed email should be like:
> "You were subcribed to AA. If you don't want to get the diggest information from
> ... , just visit
> 92922673663". It is better for subscribers - they saves one step.
Although a negative subscription confirmation saves time for
subscribers, I think many people are quire sensible on the topic of
spamming... Imagine an Evil Person who writes a script that subscribes
all her enemies to most of your slice types, categories and slice
owners; this could a) bring down your AA server for some time when the
digests are sent and b) up set the enemies. Also in my opinion it is
best to make sure that the subscription is really what somebody wants.