On Mon, Jun 30, 2008 at 09:38:32AM +0200, Eirik Schwenke wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > John Hampton skrev 26-06-2008 23:17: > | Robert C Corsaro wrote: > |> We are also thinking about implementing some sort of calendar in trac. > |> It would need to send reminders. I think it's best to have a daemon > |> running, like cron or something similar, or maybe even a custom job, and > |> building a Trac plugin to that gives it a web UI. It should be > |> extensible so ppl can implement all sorts of crazy things like closing > |> tickets after no activity for x days. Even if it could just schedule an > |> http callback with some sort of UID to remember what the task was. I > |> don't like the polling idea either. > | > | Having some sort of trac-management daemon running that would load the > | environments and then expose interfaces for plugins to use in order to > | run scheduled jobs, etc. would be fair solution. Let us know if you > | come up with something. > > This is exactly why I meant "something" should be included in core. Polling > from cron works for stuff down to resolution of about 15 minutes or so -- for > eg sending an im 5 minutes before a meeting it's not suitable IMNHO. > > I agree that using a system facility where available is a good idea in > general, > I just don't think current os scheduler deamons are suitable for what trac > needs. > > > Since everyone seemed to read my comments to mean exactly the opposite of what > I wanted to say -- to clarify: > > ~ 1) Trac needs a way to run batch commands (eg extend trac-admin as > mentioned) > > ~ 2) There should be an api for plugins to react to "time" events, probably > some > ~ kind of hook/callback/event-interface > > ~ a) this is easily implementable as a script that polls trac -- given 1) > but > ~ using cron/windows "at" is not a very *good* solution > > ~ b) a better approach would be a dedicated job que of some kind -- > ~ but it would be more complex -- which is why I'd suggest having it not > ~ run as part of trac/tracd, but rather as a separate long running python > ~ daemon (the timer part -- the job *que* should be integrated) > > ~ Note that the two solutions to the problem might use the same interface > > > The main difference I see between a) and b) is that b) would allow a tighter > integration between the registered callbacks/events/jobque than a) would. > Rather than "every 15 minutes or so" a plugin could simply register an event > along the lines of: > > ~ calendar(at=date, call=func with_params=(), recurring=0/everyMHDW) > > Maybe a separate call for recurring events and single events would be cleaner > (experience from cron/at on unix systems seems to suggest that). > > > Note also that a solution to 1) would (as Noah mentioned) solve *many* of the > scheduling-problems, because it we already have cron/at commands available > that > will help you do much as soon as you have a usable batch-interface. > > I'm not sure if trac-admin would be better than building a soild (xml)rpc api > for trac -- "trac-rpc url command params..." seems quite reasonable to me as a > batch interface. The problem with return/errorcodes/errohandling for > long-running tasks does need some consideration. RPC is never trivial to get > right. > > Then again, any batch-job that takes a "long" time (5 minutes? 20 minutes?) to > finish, would be a bit fragile to script/schedule to run often. Maybe a > trac-rpc client could internally do: > > ~ call_rpc(xxx) > ~ while True: > ~ poll_rpc_response() > ~ #Sleep... how long? > ~ #Break after ... how long? > > ~ #Continue reporting error/status etc > > > However as far as I can see 2) would still be very useful (or I see many > useful > areas for plugins where something like this should be available) -- and if we > do implement 2) it should also be usable for doing more general administrative > jobs. > > > The main reason I'd see a scheduling daemon as a separate sub-system is > exactly > to avoid the typical problems of eg coldfusion, where you have a half-baked > internal poll-based hack to run webscripts on a timer, and need something > completely different to accomplish solid maintenance scripting of your > system... And the main reason to have an internal system/interface at all is > to > have better resolution and integration between the scheduler/calendar and > trac. > > The goal shouldn't be to try to replace cron -- rather to augment trac by > making it aware of the passage of time, so to speak, and by presenting a more > powerful set of features/hooks to trac plugins.
I'm envisioning something like an extension point for a new interface, say IScheduledAction, that sits in a stand-alone script and could be called from cron, at, etc. This is very similar to what I've done with ISVNChangeListener, see particularly here: http://trac-hacks.org/browser/svnchangelistenerplugin/0.11/svnchangelistener/listener.py I'm tempted to say that this general pattern could be abstracted for everything that needs to be called from a command-line program, but for a quick solution this plugin could essentially be copied, with the mediocre support for editting post-commit-hook to mediocre support for setting up a crontab (or not). Jeff Hammel The Open Planning Project http://topp.openplans.org --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---
