[infinispan-dev] Distributed execution framework API - final review

[Emmanuel Bernard]

On 14 janv. 2011, at 17:47, Pete Muir wrote:

> 
> On 14 Jan 2011, at 15:47, Vladimir Blagojevic wrote:
> 
>> Hi,
>> 
>> Manik and I agreed on final look of distributed execution framework 
>> API[1]. We removed DistributedTask used for migrating 
>> DistributedCallable to execution nodes and replaced it with 
>> DistributedExecutorService which follows ideas of a familiar 
>> ExecutorService from util.concurrent.
>> 
>> MapReduce is still a beast of its own that can not fit into 
>> ExecutorService paradigm but I think we nailed it with a simple and easy 
>> to use API. See in particular examples provided.
>> 
>> 
>> The last item Manik and I disagree on is use of DistributedTaskContext. 
>> DistributedTaskContext is given to each DistributedCallable once it has 
>> migrated to remote node for execution. DistributedTaskContext might 
>> evolve and I'd rather keep it in the framework while Manik wants to have 
>> a simple setter on DistributedCallable:
>> 
>> setEnvironment(Cache, K...)
> 
> I prefer Manik's design, I generally try to design APIs for known use cases.

I've taken a middle ground in Bean Validation.
When a contract needed A and B for 90% of the forseable use cases (currently covered and potential alike), we went for the following

void contract(A a, B b, ContractContext context);

It has proven to be quite robust for a few reasons including:
 - people know what's really important
 - we kept doors open for the future
 - various implementations used these doors to provide provider specific extensions
 - we will use these for BV 1.1 or 2

Also, I am a bit worried about K...
in theory it looks good but how are keys going to be carried. Are they known a compilation time (where varargs shine) or are they likely going to be added to a Set and passed around (in which case varargs is a pain as you need to convert from a set to an array).