river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Brouwer <mark.brou...@cheiron.org>
Subject Re: SourceAliveRemoteEvent Part II
Date Sat, 09 Jun 2007 18:28:42 GMT
Dan Creswell wrote:

>> I think there was also a discussion with JavaSpace05.contents of how to
>> control e.g. whether the MatchSet should be populated asynchronous or
>> when done in batches what the batch size should be (AFAIK none of the
>> JavaSpace05 implementation provide any QoS constraints in this area).
>>
> 
> There was a similar discussion and it's been popping up in Blitz land
> again.  I was likely to make it a config thing for starters and then
> move to add an additional parameter to the method and include something
> like MatchSet.DEFAULT_BATCH_SIZE so one can leave it up to the space.

Hi Dan, am I right that with the 'config thing for starters' that would
mean the batch size would be global, i.e. all the same
JavaSpace05.contents operations would work with that batch size.

With regard to MatchSet.DEFAULT_BATCH_SIZE that would seem you want to
define a constant on the standardized MatchSet interface even while, as
you said, for some JavaSpace implementation it might have no meaning.

Also the extra argument would mean you add a new method to the
specification or you extend it with a Blitz specific method.

> That said it's likely due to various implementation options that might
> not do batching, this parameter could only ever be a hint which wouldn't
> fit well with the Constraints philosophy I suspect.

I don't believe an interface should show a sign of something that is in
this case implementation dependent. Therefore I see much value in using
a QoS constraint [1] for the batch size. If you assume the configuration
of proxy preparation external to the code containing your business logic
it gives you maximum flexibility.

[1] I think constraints can be used for this purpose, although if there
is a better way to deal with this QoS or implementation dependent
aspects (which shouldn't belong in the service interface) that we can
come up with is fine for me too. In a similar way as that Configuration
allows to arrange for evolution of implementations without modifying the
public API I really have felt the need a lot of times for a similar
mechanism for 'configuring' QoS aspects for a service.
-- 
Mark

Mime
View raw message