Re: Java OpenGroupware API - annotations

Burkhard,

please don't embed the whole message you are replying to ... That s***s 
big time.

First: please consider my points as suggestions. The JOGI team should 
define the JOGI API ;-) Just wanting to point out problems we already 
did wrong in the past - the issues are practical experiences.

On Montag, Sep 1, 2003, at 17:02 Europe/Berlin, Burkhard Sell wrote:
> i know the problem with counting iterators...

No this is no problem as I lined out in my other posting. If the API 
supports the availability of the count, a custom enumerator subclass 
can provide it.
Thats basic OOP ...

And again: I'm not against having a List API in *addition* for 
convenience! Its just that XML-RPC (and most other protocols ...) are 
streamed. And the enumerator is just that - an object stream - so we 
have the ideal 1:1 match.

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

Well, using the "wrong" API (one that doesn't match the characteristics 
of the backend) results in a lot of such artificial workarounds. In 
practice this is seldom worth the effort.

This is also why almost all object-relational mapping tools are 
actually less usable than direct JDBC ... They try to do too much which 
finally results in a loss.
(usually they don't work with a bit larger datasets which more or less 
destroys the whole idea in having a database backend ;-)

> but the countingproblem still exists.

There is no such problem. Either you have the count available prior 
reading all objects - in that case you can subclass enumerator - or you 
dont - in that case you need to read everything anyway.

> you can't count elements before reading the whole stream.

Of course. Which is why list is the wrong API for the task at hand ;-)

Layer:
/-------------------\
|    XML-RPC API    | - integration layer
|--------\/---------|
| Streamed Objects  | - for feeding export tools
|--------\/---------|
| Collected Objects | - for feeding table views
\-------------------/

> the API offers two methods for each kind of fetching.

In Objective-C we have it that way:

interface EODataSource
   public void setFetchSpecification(EOFetchSpecification fspec);
   public EOFetchSpecification getFetchSpecification(void);

   public Enumerator fetchEnumerator();
   public List       fetch();
end

*Unfortunately* the latter was the first in OGo which leads to exactly 
the problems I have brought up.
Do not make the same mistake and base the fetch() method on the 
fetchEnumerator.

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

Well, this is an implementation detail. I think in the case of XML-RPC 
you may actually want to have a multithreaded implementation in Java 
which goes like:

// this starts an async fetch in the second channel
Enumerator e = dataSource.fetchEnumerator();

// no we block if some record is still missing or continue
// if the producer received a XML-RPC record
while ((person = e.nextObject())
   print("Name: " + person.getName());

I would do the XML-RPC => object conversion in the main thread.

> whats about timeouts???

Good point. Timeouts can destroy/invalidate the local object graph (so 
you would actually need a transaction mechanism like the 
EOEditingContext in EOF).

The API should always use functions for retrieving relationships - 
never ivars (only for caching purposes). That way the object graph is 
not "fixed" after a fetch but can be completed in an incremental way.

Timeouts should be set on the connection object.

regards,
   Helge
-- 
OpenGroupware.org - http://www.opengroupware.org

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