Re: [infinispan-dev] Distributed execution framework API - final review
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).