How I understand this project
This post is not instructional! I'm trying to make sure I understand the goals and am looking for confirmation only =)
The goal, as I understand it, is to implement a cron hook that tracks an arbitrary number of schedules. For every schedule that has come due, bindings to that schedule are loaded. Each binding has a view that is programmatically generated and piped to actions from the actions module.
So what this looks like from the inside:
- create a schedule. This ultimately should be one of { every time cron runs | every X hours/days/minutes | once in/on x hours/days/minutes}. Most likely the first implementation will focus on "every time cron runs" to avoid getting bogged down in scheduling logic.
- Create bindings. A binding is a pairing of a schedule to a view. You can bind as many views to one schedule as you want.
- Attach actions to bindings. Every {view:schedule} pair can have a stack of arbitrary actions.
- When cron runs a number of qualifying schedules get triggered. For each schedule, its bindings are loaded. For each binding, the view is processed/rendered and piped to the action stack. Each action can operate on each view. What the view is, in this case, is a list of nodes.
So to recap with the example of publish/unpublish, you would create a view that isolates a subset of your site's content, say everything written by a certain author that was written over 14 days ago and is published. Then you'd create a schedule, let's say "daily". Then you'd create a binding between the view and the schedule. Then you'd assign actions to the binding, assigning the unpublish action and the notify author action. Then, when cron runs, it would check to see if the "daily" schedule is to run. If it is, it gets the view, passes the result set first to the unpublish action and then to the notify action.
Question: it seems like there are at least two action-injection points; for a whole view and for each node in a view. If the action is responsible for handling a whole view it needs to know how to iterate over the nodes. If the scheduler is responsible for iterating over the view and passing each node to the actions this will make existing actions more usable since they tend to be node based. Yet I can see use cases for both. For example, I can see a case for an action that sends a 1 notification if the view returns any results (if the view reports any nodes that have comments in moderation, for example).
Like I said, this is just how I would approach it based on the understanding that I "created from thin air" from the project description. If you've got other plans, I'm not trying to change them.
A good match
Your plan is a good match for what I've been envisioning, and is very similar to what flk and I chatted about yesterday.
As for the question, my feeling is that the scheduler would have an option as to how much of the view it processed, where 0 is likely the entire view. This is a lot easier than making actions be able to work on a view.
Digression: views_calendar
Let's hypothesize for a moment that the views_calendar will get written and that it will allow anything with a date field to show up in a calendar (CCK types with a date field, for example). If we plan the scheduler right, we can have automatic calendar integration for the views scheduler when that happens. Unfortunately, the idea of repetition is a bugger. It would be easy for a first pass at the views_scheduler to say that a schedule is a node with a date field. Then, when that date passes, the scheduled bindings and actions kick in. If we make the schedule a node then views_calendar integration is guaranteed.
Loose coupling
even more ideal would be if the schedule-node type were loosely coupled to the system (configurable). This would let people tie their schedules to other event schemes. For example, if someone uses CCK to create a "Conferences" node type that has a conference start date, we could use the Conference type as our schedule. Every time a conference start date passes the bindings are loaded and the actions executed. Perfect for things like closing application forms, sending email reminders of upcoming events etc.
Gah.... chickens and eggs
My last thoughts make me think that the views_calendar should actually be a prerequisite for the views scheduler!
this might sound weird but
I read your outline late yesterday night and was wondering what you was saying (hmm sleep deprivation might have had something to do with it ;P)
But when i went to sleep, i could see all the things that you said in pictorial format hehehe
Anyways the way i see it is very similar to what you have outlined....
create a schedule say we have one that's scheduled to run every Monday 12am
next We create a view and place any number of content/nodes in there and when Monday comes the cron does its job and publishes the nodes. Naturally this means binding the schedule and views together as you have stated .
With this outline we should be able to create any number of scheduled views to place content in to be auto published/unpublished at any given time.
In the case of un-publishing content, i really like that way you have outlined it, didn't think of if that way...i will have to get back to you on that
Now comes cases when an item needs to be scheduled but different time to the normal scheduling; for this i was thinking of having a random scheduling
IE a pot (view) of all items that don't belong anywhere else, this view would list all the nodes in order of how the content should be published , when its time comes pop it goes.
I haven't fully worked out how it will work, but that's how i see it.
In the case of the actions...we have pretty much the same idea.
What about event_repeat?
Event_repeat has some pretty sophisticated 'second thursday of every other month' type scheduling capability. I guess there are two possible ways this might be used:
I favor your second approach
and think that it falls outside of the scope of this student's project. At least, sophisticated scheduling should come at the end, if there is time. Mentors, agree?
Ideally the scheduler api it
Ideally the scheduler api it uses is such that it can include an easy way to schedule views, but is also open enough that alternative methods of scheduling are possible. Thus a bit of glue between an event and scheduler.