Re: Java OpenGroupware API - annotations

Werner Schuster wrote:
>>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;
> 
> 

i know the problem with counting iterators...
i have them too :(

an own implementation of the List interface should fix the problem
in almost the same way like implementing iterators but the benefits
of list will be obtained.

but the countingproblem still exists.
you can't count elements before reading the whole stream.

let't think about a third way ;):
the API offers two methods for each kind of fetching.

the first returns a java.util.List implementation
the second return an own (java.util.list inherited) list implementation.

so you define a List interface:
   extends java.util.List

add some methods like
   /**Returns true if all elements fetched from server, false otherwise*/
   fetchCompleted()

   /**Retrieves all elements from server and closes the connection.
    * <p><strong>Use with care!!!</strong></p>
    */
   fetchAll() or completeFetch()

create an implementation of this interface
   overwrite size() method and return -1 until fetchCompleted
   overwrite the get(int) method do fetch all elements until index
   implement a private Object getNextElement() method
   to read the next element from stream

   overwrite remove(int) and remove(Object) methods to check if the
   element to remove already fetched

   overwrite iterator() method.....

   and so on ;)


short version:
implementing own List should be better then only creating a new 
iterator. but i think there should be two way to get elements from server.

tell me your minds.

@helge

whats about the open connections?
there are to ways of doing the fetch

a) create a connection to server, process the query and leave the 
connection open for reading the elements

b) save the query and execute it only if the first element needed...
but the connection is open too (a little later but open)....

whats about timeouts???

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

i did ;)

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

i don't know. but sometimes you did ;)

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

no problem...do so ;)

> 
> murphee
>  (JOGI Team)
> 
> 

regards
burkhard

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