-----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. Best regards, - -- ~ .---. Eirik Schwenke <[EMAIL PROTECTED]> ( NSD ) Harald Hårfagresgate 29 Rom 150 ~ '---' N-5007 Bergen tlf: (555) 889 13 ~ GPG-key at pgp.mit.edu Id 0x8AA3392C -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIaI14xUW7FIqjOSwRAvKDAJ9XNTiekEXGHUnjicJsFUg6mHB19gCeNre3 z/8w8hBizXQCZV/xiRGe82A= =CePA -----END PGP SIGNATURE----- --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
