Re: Java OpenGroupware API - annotations

Helge Hess wrote:
> 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).

java knows enumerations too.
but sometimes sun created a collection frameworks.

they defined some interfaces like List, Collection, ...
these Interfaces returns Iterators not Enumerations,
but it almost the same under a new name ;)

> 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.

this you can fix if the client uses the iterator method of the new
list implementation.

but there are some cases the client needs think like element counting,
getting elements by index, ...

so you *need* a list interface.
in those cases if you only provide a iterator the client will copy all 
elements into its own list/array/...

> 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.

what will the client do with this records...
mostly it'll display them...so you need all elements in RAM.

otherwise you can use the iterator() method

> > > > 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

burkhard

--
OpenGroupware.org XML-RPC
xmlrpc@xxxxxxxxxxxxxxxxx
http://mail.opengroupware.org/mailman/listinfo/xmlrpc