Re: Depending on policy [was Re: Implementation of take (multiple) in Jini starter kit]

John McClain - Sun Microsystems, Inc. wrote:
>> Could you perhaps rephrase the question?
>
> I can try. By there nature a specifications has to leave implementations
> some wiggle room. Part of this is because you want to allow different
> implementation to make different trade-offs and part of this is because
> often there is no useful place to draw a line. In practice all
> implementation will provide a higher level of service than the minimum
> required by the specification.

True.   Is there any place where the reference implementation ("starter
kit") javadoc is available?   The vagueness of the specification javadoc
is understandable, as you say, but since I have not found the javadocs
for the reference implementation, I've been forced to make some "best
guesses" about what certain behaviors would be (which I'd rather not do).

Better understanding the implemented behavior for things like MatchSet
would be a good thing.

> The question is how comfortable do people
> feel writing code that depends on these "higher levels of service" that
> aren't guaranteed by the specification.

My colleagues and I would feel pretty comfortable depending on the
"higher levels of service".

There are several reasons for this:
1) We don't switch implementations of Javaspace every other day.

2) Most of our space usage occurs within a wrapper, which (among other
niceties) provides a central place to make a change should we switch
Javaspace versions.    This allows us to manually implement or
explicitly break any features we were previously using if we should
switch versions.

For instance, the switch from AdminIterator to MatchSet was handled
within the wrapper.   Likewise, we back-implemented take multiple with a
single template and explicitly broke take multiple with many templates
for versions not conforming to the JavaSpace05 spec.

> The question then becomes if you are writing a JavaSpace05 client
> application and you know there are two entries in the space and you want
> them both removed do you write :
>
>    while (true) {
>        Collection c = space.take(templates, null, 0, 2);
>        if (c.isEmpty())
>            break;
>    }
>
>    or
>
>    space.take(templates, null, 0 2);
>
> Option one will work with any JavaSpace05 implementation, option two
> will only work with some, but is a lot easier, and it seems likely that
> you could configure most (all?) spaces implementations to work with
> option two so what's the harm? (he asked in a devil's advocate sort of
> way.) Would people feel comfortable writing code like option two even
> though it was dependent on behavior not guaranteed by the spec?

Option 2 is the better option for us, as long as we grok the
implementation we're using.   Because of the wrapper, we're largely
insulated from the potential harm.   Switching space implementations
ideally boils down to creating one or two extra classes.

James

===========================================================================
To unsubscribe, send email to [email protected] and include in the body
of the message "signoff JAVASPACES-USERS".  For general help, send email to
[email protected] and include in the body of the message "help".

To view past JAVASPACES-USERS postings, please see:
http://archives.java.sun.com/archives/javaspaces-users.html