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
xmlrpc@xxxxxxxxxxxxxxxxx
http://mail.opengroupware.org/mailman/listinfo/xmlrpc
| 
