I also suggest to not tie this to acs_events. Firstly it is only calendar that uses acs_events and if I had the time and data I would probably just update the calendar data model by removing acs_events: this package has been there for more than two years to provide an abstraction to hook other packages' data into calendar and nobody has used it. Conceptually views would fit in here much better.
By using the object_id you can set reminders on arbitrary objects. What about just allowing the user to set an arbitrary reminder time? And put some intelligence only into the proposal, *not* into the database. Like this - meta-tcl code on the set-reminder page:
if object_type equals calendar
find_out event time
substract 1 day if > 1 week away
substract 8 hours < 1 week away
substract 1 hour if < 2 days away
propose this setting as event time
elseif object_type equals project_task
always substract 1 day
propose this setting as event time
I'd just go ahead and have object_id, reminder_time, reminder_user_id or reminder_party_id in this table.
Subsequent versions of course need to be i18nized, reminder text need to be editable etc. But for starters a very light-weight package should do it.
