Re: Java OpenGroupware API - annotations

> On Montag, Sep 1, 2003, at 17:38 Europe/Berlin, Burkhard Sell wrote:
>> but there are some cases the client needs think like element counting,
>> getting elements by index, ...
> Yes, in that case you need to read all elements anyway. Nothing against
> an additional, higher level, method which does that.

Hmm... one thing I noted  in this conversation,
 is the different conceptions about how high-level Enumerators (Iterators)
are;

I personally think of Enumerator as more high-level than Lists; the idea
is that with an I don't have to think about what type of Container
I am accessing; I simply call "next()" until nothing is left;

A List, for me, is lower level, as it is more similar to the actual
memory layout (one element after the other) and I have to use a counter
var to walk the list.


So, in my eyes, the Enumerator (Iterator) is more of a convenience
thing that most people will use;

I have a problem with only offering an Enumerator and basing all
accesses on it (eg. some convenience List class, that uses it);

I remember using an Image Manipulation Library (in C++) that basically
used this approach; the base class offered access to its data only
by way of an STL iterator; which is all nice and OO and whatever,
if you only access every pixel from the 1. to the last (row by row).
But its a real pain in the neck, if you want to access a specific pixel;
I suppose, the programmers of this lib realized this and added some
methods for indexed access (ie. something like getAt(x,y) );
The problem was, they didn't access the data directly, but by way of
the iterators... If you're not groaning with disbelief yet, think
about this: if you want to access the pixel at pos. (100,100), you have to
have 100*100 iterations with the iterator...;  Now imagine the performance
of a program, that has to walk the pixel data from the bottom-right to
the top-left pixel...

I know, that DB and Image Manipulations are different domains and whats
bad for one need not be bad for the other, but thats one reason I am
bit sceptic about using only Enumerators.


>> in those cases if you only provide a iterator the client will copy all
>>  elements into its own list/array/...
> Of course. Isn't there Java API like
>    list = List(Enumerator e)
> ?

Hmm... don't think so; though it can easily be done (by "easily" mean
a just few lines of code);

>> mostly it'll display them...so you need all elements in RAM.
> If you strictly focus on an OGo specific GUI client, this may be true.
> In any other case it is not.
> Mostly you will *not* keep them in memory - because you can't!

Hmm... but thinking about OG.o ... would there really be such
huge amounts of data? I mean, how many Person, Enterprise, ... objects
are we talking about here?


> JSP pages
> - render object, forget object, render object, forget object
> Export tools
> - export CSV line, forget object, export CSV line, forget object

True, it would be nice to work with a constant amount of data
with one of these (basically just keeping the currently used
elements in memory);

> Glow GUI Client
> - map JOGI Person to SDBC Contact, forget object, etc
> OGo GUI Client
> - extract attributes you need (name,street,email), forget object

Hmmm... I don't think so; for GUI applications, the  MVC approach would
be used, so the Objects returned by JOGI would be used as models that
store the data, and the GUI uses this data to display it; so, if you
want to keep displaying the data, you need the stuff in memory;


Hmm... it seems, like there might actually be some need for ... hm...
two APIs in JOGI; they would be like DOM and SAX for XML;
 -the current JOGI implementation would be like DOM, which is easy to
use, but memory intensive and unusable for big amounts of data;
 - the other would only allow to process data serially as it comes in,
but would use only constant memory;  but it would still offer high-level
objects (Account, Person,...) to easily access the data (so you don't
have to fiddle with XmlRpc results);


Although... offering a streaming API that really uses the advantages of
streaming (ie. allowing access the first elements while the rest
is still on the road) has its own set of problems;
Well... actually only one problem: we would have to write our own XmlRpc
implementation, because currently available ones don't do that (at least
as far as I know); if you call a function that returns a list of things,
the method call returns when the *whole* list has been retrieved and made
available as a Java List;

Of course, doing this shouldn't be difficult (famous last words...)
but I would prefer not to, if there is a way around (although I
suppose there is no other way);


murphee
 (JOGI Team)


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