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). > I don't see why you couldn't make a generic interface and have different plugins for different ways of doing things. You could have the PollingSchedularPlugin and then some RealtimeSchedularPlugin. Or any other thing you want. The key is, an interface to create scheduled jobs, and and interface to call back those jobs into trac. The PollingSchedularPlugin could be implemented completely in Trac and with something outside just calling a URL. More sophisticated solutions could be external.
> > 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. I would think that you implement a notification interface for "job" completion. Then you can do what you want with the results. The "cron" mechanize should no very little about trac. Just how to schedule a callback and execute a callback. > > 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. > The cool thing about Quartz as apposed to cron, was that it had a nice API, and is database driven. I wonder if there is something similar for python. I certainly wouldn't suggest writing something like that. Quartz and cron are major projects in their own right, to say the least. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
