Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Date: Tue, 2 Nov 2004 23:11:37 +0100 (CET)
From: Giacomo Pati <giacomo@apache.org>
To: dev@cocoon.apache.org
Subject: Re: Implementation of the Continuations checker
In-Reply-To: <8D3AA844-2AB4-11D9-AD9E-000D93C1F3E2@hippo.nl>
Message-ID: <Pine.LNX.4.61.0411022228060.10023@lapgp.otego.com>
References: <4183C582.5010004@dslextreme.com>
 <3AC7F738-2A9D-11D9-AD9E-000D93C1F3E2@hippo.nl>
 <Pine.LNX.4.61.0410302056480.9982@lapgp.otego.com>
 <8D3AA844-2AB4-11D9-AD9E-000D93C1F3E2@hippo.nl>
X-GPG-PUBLIC_KEY: 
 http://pks.gpg.cz:11371/pks/lookup?op=get&search=0x371005D8BA4A9F94
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Virus-Checked: Checked
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N


Ok, guys, lets see if we can find a consensus for this issue.

The issues have been:

- Excalibur Event package is deprecated. We need a replacement of those
   functionalities we are in need for the core (scheduling Runnables once,
   with delays, periodically)
- Some stated that the cron block seems too heavy for that (I take that as
   a veto :-)
- I'd like to have Thread spawning in one single component so that users
   of "sophisticated" EAS can write their own implementation of the
   following proposed interfaces.

A BackgroundManager/AsyncManager (name it as you like) manages ThreadPools 
(named and anonymous ones) and executions of Runnables using them:

   interface ThreadPool {
     void execute( Runnable command );
     TYPE getPROPERTY(); // what ever values should be exposed
   }

   interface BackgroundManager {
     void execute( Runnable command );   *1 *a
     void execute( Runnable command,
                   long delay );         *1 *b
     void execute( Runnable command,
                   long delay,
                   long period );        *1 *c
     void execute( String threadPoolName,
                   Runnable command );   *2 *a
     void execute( String threadPoolName,
                   Runnable command,
                   long delay );         *2 *b
     void execute( String threadPoolName,
                   Runnable command,
                   long delay,
                   long period );        *2 *c
     ThreadPool createPool( String name, ... ) *3
     ThreadPool createPool( ... ) *4
   }

   *1 runs a Runnable in the default ThreadPool
   *2 runs a Runnable in a named ThreadPool
   *3 creates a named ThreadPool (shared usage of ThreadPools)
   *4 creates a anonymous ThreadPool (private usage by some client)
   *a runs command once
   *b runs command after a delay
   *c runs command periodically after a delay

A DefaultBackgroundManager implementation will create ThreadPools based on 
one of concurrent-utils Executors depending on the configuration (this is 
ready to use code from the cron block).

The settings of the default ThreadPool will be based on the current 
CommandManager configuration. The configuration of the default ThreadPool 
can be overwritten using normal configuration methods (see 
src/blocks/cron/conf/cron.xconf adding a name attribute). Named 
ThreadPools can be created at strartup by configuration.

What do you think about this as a replacement for the Event package?

-- 
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com