Re: Java OpenGroupware API - annotations

> Burkhard Sell wrote:
>> i took a look @ your JOGI stuff.
>> It's a very nice thing ;)

Thanks!

>>  i already told with helge about that and we think this is not the
>> best way doing so.
>>  if there are queries with large results, this results in a expensive
>> utilization of resources. the better way should be to return iterator.

Well, when we (JOGI Team) first talked to you guys about our API,
either you or Helge (hm... can't remember), mentioned that too.


We didn't ignore that advice, and actually considered it at first.

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

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

And: with the Java Collections List, an Iterator object is only an
"iterator()" call away;


So... those are our considerations on that topic; If you find a
flaw in the logic, please point it out, and we shall reconsider;


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


>>  maybe short queries can get slower but large queries will be fasten
>> up extremly. i think in most cases the client will iterate over the
>> lists anyway,  don't they?

I suppose;


>>  is it possible to change your API. please think about that.

We would be greatful if you could give us your opinion on our
considerations that I stated above;


>>  it seems you're importing the libs using the "add external jar
>> feature". the better way is using variables or the "add jar" feature,
>> so it runs everywhere without changing any settings.

OK, noted; although, I don't think I have commited the .project or
.classpath lately;

>> u're using "net.sourceforge.ogojogi...".
>> ok, currently the project is hosted there but

well, actually, we didn't use that namespace because of
the project is hosted there, but because we using this
convention, we would have a unique namespace, without the
risk of clashing with another library's Namespace;

>>   think  "org.opengroupware.ogojogi"
>> sounds much better...don't it?

actually... it does; hm... I suppose, for our first real release
(not "EarlyAccess") we will change the Namespace to
org.opengroupware.ogojogi;

>> and eclipse supports refactoring ;)

I know, we actually had used the namespace "jogi.*" during initial
development, and had changed it to the Sourceforge one just prior
to the first Release (using Eclipses refactoring capabilities);


>> if you need/want help for your project...ask me for!

... bad move; we will surely take this offer seriously ;-)

murphee
 (JOGI Team)


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