river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: Space/outrigger suggestions (remote iterator vs. collection)
Date Wed, 19 Jan 2011 01:06:01 GMT
Patricia Shanahan wrote:
> James Grahn wrote:
>> It (finally) occurred to me that we can have our cake and eat it too 
>> in this case.
>> We can have the sweet deliciousness of API symmetry and retain the 
>> implementation advantages of remote iterator & collection by having 
>> both take-multiple and contents return:
>> Iterable.
>> This would introduce more flexibility in the spec, allowing more 
>> design decisions to be made by those implementing, while presenting a 
>> uniform external return type to the users.   (A relatively standard 
>> one at that.)
>> When I was looking at the remote iterator earlier, I was thinking it 
>> would probably be best to have it implement Iterator and probably 
>> Iterable anyway.
>> The only potential sour note is that Iterable is a 1.5 interface.   
>> So that's come up again.
> We could define our own Iterable, in one of our packages, with the 
> same definition as java.util.Iterable.
> However, it would not have the nice for-loop syntax, and we could 
> spend a lot of time building up workarounds for not being 1.5.
> Patricia
The interesting part about a mixed distributed environment is that it is 
possible to have a Service API that requires a particular java platform, 
clients that cannot support that Service API, can't look it up.  Also 
earlier java / jini platforms that lookup a Service that provides a 
proxy with later version bytecode will not be unmarshalled, this is 
actually acceptable as part of the spec.

Because changing a Service API creates a new API, it is actually 
distinct, clients using the earlier Service, will get service proxy's of 
that type, while clients that look up the latter Service api will get 
different service instances that have a different type.

It is best to use a different class name when we change a Service API 

Part of my interest in a modular build relates to the possibility of 
handling platform dependencies.



View raw message