Re: [Zope-dev] Re: Event Timer Service for Zope 2.8

2005-07-25 Thread Chris McDonough
On Tue, 2005-07-26 at 09:44 +1000, Dylan Jay wrote:
 So to summarise:
 
 - ClockServer is a good idea to put in the core but needs to made python 
 only.

Yes, at least for inclusion into Zope.

 - Schedular from cvs is probably the best one to use but not neccerily 
 in the core.

Not sure about best (because I've never really used any others) but I
have the opinion that we should hold off on that for the core, yes.

 Does the schedular work with ClockServer by puting the notify path in 
 zope.conf or will the schedular need to be modified to subscribe to the 
 clock?

Yup.  The simplest way it can work is by putting the CVS scheduler's
notify method in a path in zope.conf.  This implies that the scheduler
has received a time event for now.  If you wanted to get more fancy,
and you were into events you could create another script or product that
actually sent a time event, and the ClockServer could call that.
There's almost no reason to do this if all you want is the scheduler,
though.

 So whats next? Does one put a feature request in the collector these 
 days or is there another process?

It's now officially on my todo list for 2.9.0 (along with blobs, and
maybe zodb connection policies).

- C


 
 Chris McDonough wrote:
  On Sun, 2005-07-24 at 11:51 +1000, Dylan Jay wrote:
  
 Chris McDonough wrote:
 
 On Fri, 2005-07-22 at 13:11 +0200, Florent Guillaume wrote:
 
 
 Dylan Jay  [EMAIL PROTECTED] wrote:
 
 
 Tres Seaver wrote:
 
 Myself I'm for having ClockServer in the core, if Chris and others agree.
 
 
 It's fine with me.  We maybe just need to remove the C extension in
 it... someone (you?) provided a pure python implementation of what it
 does that probably runs just as fast.
 
 There is also TimerService by Nikolay Kim. Does that work in the same 
 way?
  
  
  I don't know.  As far as I know, ClockServer is the only product that
  works as a medusa server as opposed to a separate thread or process
  (which is really its only attraction).
  
  
  One nice feature of this is that products such as a scheduler 
 subscribe to its tick so that many products can benifit from the clock. 
 This seems more flexible to me, rather than putting the path to be 
 called in the zope.conf.
  
  
  This is typically the domain of an event service (components subscribe
  to events, and the service contacts all of them when one of those events
  happens).  I agree this is very useful but I'd try to implement it in
  terms of a more general event service.  The clock is really just a clock
  and it should do not much more.
  
  
 Another nice feature is a plugin archetecture shown by
 http://www.last-bastion.net/portal_zpydoc/Products.ZScheduler.html
 Here one kind of clock can be replaced by another so for instance a cron 
 job could be used instead of the clockservice. That product also had a 
 singlethreaded clock that ensured the next tick didn't occur until the 
 last finished. Personally I think that is the schedulers job rather than 
 the clocks but I do think allowing an cron override is a good idea.
 So perhaps the archetecture could look something like
 
 ClockService (outside zope)
 v
 Clock ControlPanel (inside zope... could also be called via cron wget)
 v v
 Scheduler A  Product X
 
 In other words products subscribe to the clock control panel in order to 
 get a regular call back and the clock control panel is driver from 
 clockserver or some other outside source.
  
  
  That'd be fine but IMHO a scheduler should probably still be implemented
  on top of one or more dumb clocks and clock ticks should cause events
  to fire (if necessary) based on an event system that can be used for
  other things.
  
  
 Or alternatively you could just make the clock control panel a scheduler 
 and say that anyone wanting a clock tick has to register a recurring task.
 
 
 
 I wouldn't be apt include the Scheduler product in the core.  I think it
 may be a tad too complicated.
 
 Do you mean the zope cvs scheduler? 
  
  
  Yes.
  
  
 I think this is the simplest 
 implementation I've seen. It is API friendly in that it allows for code 
 to add events reasonably easily. Its UI could be improved somewhat. The 
 Zscheduler above as a nicer UI that could be borrowed.
 I think the cvs scheduler needs to at least have an option of not 
 allowing more than one task at a time to run. This could be implemented 
 in the callers code but it is a nice service. At the very least the 
 current code needs to be fixed as it causes conflicts if its notify is 
 called before the last one has finished.
  
  
  It also currently depends on the Event product (although that would be
  easy to remove).
  
  But FWIW, I'm not interested in putting any scheduler in the core
  personally right away, just a clock for now.  This is mostly for
  maintenance reasons.  If we did put one in, I'd probably try to
  implement it in Zope 3 and bridge it to Zope 2 using the Zope 3 event
  service and Five.
  
 

Re: [Zope-dev] Re: Event Timer Service for Zope 2.8

2005-07-24 Thread Chris McDonough
On Sun, 2005-07-24 at 11:51 +1000, Dylan Jay wrote:
 Chris McDonough wrote:
  On Fri, 2005-07-22 at 13:11 +0200, Florent Guillaume wrote:
  
 Dylan Jay  [EMAIL PROTECTED] wrote:
 
 Tres Seaver wrote:
 
 Myself I'm for having ClockServer in the core, if Chris and others agree.
  
  
  It's fine with me.  We maybe just need to remove the C extension in
  it... someone (you?) provided a pure python implementation of what it
  does that probably runs just as fast.
 
 There is also TimerService by Nikolay Kim. Does that work in the same 
 way?

I don't know.  As far as I know, ClockServer is the only product that
works as a medusa server as opposed to a separate thread or process
(which is really its only attraction).

  One nice feature of this is that products such as a scheduler 
 subscribe to its tick so that many products can benifit from the clock. 
 This seems more flexible to me, rather than putting the path to be 
 called in the zope.conf.

This is typically the domain of an event service (components subscribe
to events, and the service contacts all of them when one of those events
happens).  I agree this is very useful but I'd try to implement it in
terms of a more general event service.  The clock is really just a clock
and it should do not much more.

 Another nice feature is a plugin archetecture shown by
 http://www.last-bastion.net/portal_zpydoc/Products.ZScheduler.html
 Here one kind of clock can be replaced by another so for instance a cron 
 job could be used instead of the clockservice. That product also had a 
 singlethreaded clock that ensured the next tick didn't occur until the 
 last finished. Personally I think that is the schedulers job rather than 
 the clocks but I do think allowing an cron override is a good idea.
 So perhaps the archetecture could look something like
 
 ClockService (outside zope)
 v
 Clock ControlPanel (inside zope... could also be called via cron wget)
 v v
 Scheduler A  Product X
 
 In other words products subscribe to the clock control panel in order to 
 get a regular call back and the clock control panel is driver from 
 clockserver or some other outside source.

That'd be fine but IMHO a scheduler should probably still be implemented
on top of one or more dumb clocks and clock ticks should cause events
to fire (if necessary) based on an event system that can be used for
other things.

 Or alternatively you could just make the clock control panel a scheduler 
 and say that anyone wanting a clock tick has to register a recurring task.
 
 
  I wouldn't be apt include the Scheduler product in the core.  I think it
  may be a tad too complicated.
 
 Do you mean the zope cvs scheduler? 

Yes.

 I think this is the simplest 
 implementation I've seen. It is API friendly in that it allows for code 
 to add events reasonably easily. Its UI could be improved somewhat. The 
 Zscheduler above as a nicer UI that could be borrowed.
 I think the cvs scheduler needs to at least have an option of not 
 allowing more than one task at a time to run. This could be implemented 
 in the callers code but it is a nice service. At the very least the 
 current code needs to be fixed as it causes conflicts if its notify is 
 called before the last one has finished.

It also currently depends on the Event product (although that would be
easy to remove).

But FWIW, I'm not interested in putting any scheduler in the core
personally right away, just a clock for now.  This is mostly for
maintenance reasons.  If we did put one in, I'd probably try to
implement it in Zope 3 and bridge it to Zope 2 using the Zope 3 event
service and Five.

  The Event product is likely superseded by the Zope 3 event system
  included in Five.
 
 Is there really a need for an event system? I can't see where the actual 
 event system is even used in the cvs scheduler. Surely a listener/talker 
 pattern is easy enough to implement?

The Scheduler product indeed subscribes to an event service in order to
accept ITimeEvent and IScheduledEvent event notifications.  See its
notify method in Scheduler.Scheduler.

The pattern is easy to implement but it is useful to have one component
handle event registration and notification so you don't have to
reimplement it over and over.

- C


___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Re: Event Timer Service for Zope 2.8

2005-07-23 Thread Chris McDonough
On Fri, 2005-07-22 at 13:11 +0200, Florent Guillaume wrote:
 Dylan Jay  [EMAIL PROTECTED] wrote:
  Tres Seaver wrote:
   -BEGIN PGP SIGNED MESSAGE-
   Hash: SHA1
  
   Chris' ClockServer removes the need for such a thread, by hooking
   ZServer's mainloop to generate the faux request needed to kick off
   async processing.  A crontab - like schedule can be driven equally
   well from ClockScheduler as from a separate thread.
  
  So what's wrong with including ClockServer in the core or making it 
  easier to install? (ie not having to put packages in the python path 
  which is hard with some hosting arrangements)
  
  And what's the argument against a core scheduler regardless of a clock? 
  Isn't running background tasks a common need amoungst many very 
  different tools and therefore a interstructure issue?
 
 Myself I'm for having ClockServer in the core, if Chris and others agree.

It's fine with me.  We maybe just need to remove the C extension in
it... someone (you?) provided a pure python implementation of what it
does that probably runs just as fast.

I wouldn't be apt include the Scheduler product in the core.  I think it
may be a tad too complicated.

The Event product is likely superseded by the Zope 3 event system
included in Five.

- C


___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Re: Event Timer Service for Zope 2.8

2005-07-22 Thread Florent Guillaume
Dylan Jay  [EMAIL PROTECTED] wrote:
 Tres Seaver wrote:
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
 
  Chris' ClockServer removes the need for such a thread, by hooking
  ZServer's mainloop to generate the faux request needed to kick off
  async processing.  A crontab - like schedule can be driven equally
  well from ClockScheduler as from a separate thread.
 
 So what's wrong with including ClockServer in the core or making it 
 easier to install? (ie not having to put packages in the python path 
 which is hard with some hosting arrangements)
 
 And what's the argument against a core scheduler regardless of a clock? 
 Isn't running background tasks a common need amoungst many very 
 different tools and therefore a interstructure issue?

Myself I'm for having ClockServer in the core, if Chris and others agree.

Florent

-- 
Florent Guillaume, Nuxeo (Paris, France)   CTO, Director of RD
+33 1 40 33 71 59   http://nuxeo.com   [EMAIL PROTECTED]
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )