> On 2007-10-23 15:21, Dirk Meyer wrote:
>> As for the API I'm thinking of at/schedule, remove and list.
>>
>> | t = CronTimer(callback)
>> | t.at("*:15")
>> | t.at("*:20")
>> | t.list() => [ "*:15", "*:20" ]
>
> Is it necessary to support multiple times per CronTimer object? I think
> this just complicates the interface. If the user wants the callback to
> fire at multiple times he can just instantiate multiple CronTimer objects.
>
> And ...
>
> On 2007-10-23 16:18, Duncan Webb wrote:
>> I meant when you set the time, to me:
>> | t.at((min=15,sec=30))
>> is clearer and more explicit than
>> | t.at("*:15:30")
>>
>> or to run something every 15 minutes
>> | t.at((mins=15))
>> by making it plural.
>
> I'm not sure that it is clearer and more explicit. Maybe marginally.
> Both are ambiguous, and Duncan's has the problem of creating confusion
> over the distinction of mins and min next year when we all forget this
> discussion. I actually prefer dischi's suggestion, using wildcards.
>
> Alternatively, since it's called CronTimer, we could borrow from
> well-established format that cron itself uses. Sure this is a bit
> baroque, but it's ubiquitous and lots of people already know it, and the
> name CronTimer implies that we ought to support this format. Since
> crontab defines only minute precision, we could extend this with another
> field for second precision.
>
> t.schedule('* * * * * *') # run every second
>
> Or perhaps allow for missing fields, anchored from the right. So
> missing fields on the left will be assumed *:
>
> t.schedule('*') # run every second
> t.schedule('*/10') # run every ten seconds
> t.schedule('*/5 0') # run every 5 minutes
> t.schedule('18-23,0-6 0 0') # run on the hour between 6pm-6am
>
>
> Another possibility is to support a human readable format, like at(1)
> itself uses. This has the benefit of providing very readable code for
> the API user, while adding a fair bit of complexity to the
> implementation of CronTimer:
>
> t.at('every 5 seconds')
> t.at('midnight')
> t.at('every other minute')
Not being a sys admin, I must look up the cron command syntax every time :)
May be the name CronTimer is misleading as cron stands for "Command Run
On" so perhaps it should be called TimerAt or AtTimer.
The problem with string arguments as they are relatively difficult to
parse, using **kwargs providing a dict object may be simpler to implement
from both the caller and callee sides.
Just some thoughts after a night's sleep.
Duncan
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Freevo-devel mailing list
Freevo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freevo-devel
