Re: Java OpenGroupware API - annotations

Werner Schuster wrote:
> One thing that bothers me about the Iterators, is that you cannot
> find out the number of returned results. With a List, you simply
> call size(), which could be a O(1) operation; when returning an Iterator,
> you also have no good way of finding that out (besides walking the Iterator);

Well, I don't know the Iterator API, only the Enumerator one (which is 
also available in Objective-C).
You could easily extend the Enumerator interface to include the size (eg 
this is pretty usual in SQL enumerators since most database send the 
size in advance).

> We return a java.util.List on purpose, since this allows us to choose the
> implementation of the returned List. Currently we return ArrayLists
> (or Vectors... hm... gotta look that up), but as an optimization
> I have something of a lazy List in mind; this could basically do
> the same thing as an Iterator, and not load anything at first,
> only when something is accessed;

This still has the problem that all the objects (therefore the whole 
database) will end up in the RAM. Eg if you use JOGI to implement some 
kind of integration or export tool or for writing some JSP which formats 
the result in XML, this will blow up your memory usage unnecessarily.

In any way you could still provide a convenience method which returns an 
array but the Enumerator should be the primary implementation since it 
is more low level.

Another advantage is that the Enumerator improves concurrency and 
therefore reduces latency. While one thread may continue reading XML 
records from the socket, the main thread may already convert the records 
into objects.
(yes, I see that you could also write an array which fetches 
incrementaly and blocks if some record is not yet available - but why 
adding that complexity?).

> This brings the benefits of giving the user a List (like, allowing
> the user to access contents by index instead of being forced to
> walk the entire Iterator if not the first but n-th element is desired,
> accessing the size,...).

Again, if you have thousands of records this will hit you big time 
because indexed access is wrong(tm) for big collections.

>>> so the client gets the iterator and each element is read when its
>>>needed.
> Well, my idea of some lazy List implementation would work the same
> way; if someone uses  resultList.get(0), the we only read the
> 0th element, and do not fill all the rest unless those elements
> are requested.

Well, IMHO its the wrong approach. Why artificially hide the fact that 
the IO is happening in a streamed way? This should be the primary 
interface and you may provide convenience methods on top of it.

Again, your approach is likely to result in huge RAM requirements unless 
you make the list extraordinarily smart ;-)

(just giving hints on issues which already hit us in the Objective-C 
APIs as well ...)

>>>  think  "org.opengroupware.ogojogi"

BTW: why ogojogi instead of just "org.opengroupware.jogi"?

regards,
   Helge
-- 
http://www.opengroupware.org/

-- 
OpenGroupware.org XML-RPC
[email protected]
http://mail.opengroupware.org/mailman/listinfo/xmlrpc