Re: maxEntries in contents()

Jeff Ramsdale <[email protected]>
Newsgroups gmane.comp.java.sun.javaspaces
Message-ID <6E58A7C8A2126D44ACBC06D1DA24CFD13FAD63@blv2-exc-01.siq.solutionsiq.com>
I consider clarification text to be on the order of a bug fix (if a
minor one) that should not require spec-like approval. If the use of
JavaDoc as a spec repository is a procedural inhibitor to improving
Jini in a way that doesn't itself change the spec then I would suggest
the spec shouldn't reside in the JavaDocs. But then again I feel that
way regardless. There's a lot of spec-motivated boilerplate text in
the JavaDocs that makes it more difficult than it need be to use the
Jini libraries. If the spec is to be holy, then how about we make the
JavaDoc less so--that way the masses can get their lay interpretation
of the spec in the modern tongue.
 
Jeff

 
________________________________

From: John McClain - Sun Microsystems, Inc.
[mailto:[email protected]]
Sent: Wed 11/30/2005 11:16 AM
To: [email protected]
Subject: Re: maxEntries in contents()



I have to admit, when I read "the maximum number of entries to remove
from the set via MatchSet.next calls" in Dan's message (for some
reason
I got Dan's message first....) I was a bit confused too....

Not sure why I didn't write something like "the maximum number of
entries to be yielded by MatchSet.next calls", or maybe "the maximum
number of entries to return before the MatchSet is considered
exhausted". I suspect I had latched onto the idea of next deleting
entries from the match set and wanted to stick with that notion.

As for modifying the JavaDoc I need to think about that. There is the
procedural issue that it is now an approved community standard and
certain types of changes would require a vote. More deeply we (Sun's
Jini team) try to keep non-normative text (like motivations, uses
cases,
examples, etc.) out of our specs.

One idea that does appeal to me is writing some sort of companion
document to the JavaSpace05/MatchSet/AvailabilityEvent JavaDoc that
can
include non-normative text, be less precise, and more user oriented. I
suspect it would focus on the expected usage models. Not sure what
would
be the best way to make this new document visible (then there is the
time problem too)



===========================================================================
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.