Re: [Gnue-dev] Appserver Interface Issues

[Reinhard Mueller]

Hi, Jan,

thanks for your comments.

Am Sam, 2002-10-26 um 13.19 schrieb Jan Ischebeck:
> 1. PERFORMANCE: for a simple form with 4 entries, 10-12 rpc calls have to be
> executed just for initialisation and loading the first record.
> Because most of the rpc calls have to be called sequentaly, the whole
> initialisation takes ca. 10 sec on a LOCAL connection. Loading a new
> record takes 5 rpc calls. 

I am quite surprised that RPC calls are so expensive (performance wise).
Doesn't that mean that a single RPC call takes a whole second on a local
connection??

In this case, I'm not sure whether XMLRPC is usable at all for our case.

> 2. OVERHEAD+UNCONVINIENCE: In the actual implementation we use a list
> of instances on the appserver side. But this list is not really navigatable,
> we just can fetch one element after the other. Because of this, the whole 
> list has to be stored on client side too. and prev, next functionality
> has to provided on client side. It would be good to define the role of
> the geasList class  more concrete. So we can decide if we keep it as
> lean as now, or if we add some navigation functionality. Another option
> is to add the navigation functionality to the instances. a geasList
> could also be similar to java iterator. ...

I don't know java iterator (well, to be precise, I don't know Java at
all), but I would strongly recommend to put the needed navigation
functionality into the server. The server is the part that should handle
caching and all that stuff, so navigation _has_ to be there IMHO.

What navigation functions are you missing? Is it just a "last" and
"previous", or is it more that's needed?

> a possible RESOLUTION for the PERFORMANCE problem:
>   1. combine some calls, like: 
>         a) reqeuestNewSession+login(user,pass) ->
>          reqeuestNewSession(user,pass)
>       b)
>       createList(table)+setPrefetch()+setConditions+setSort+populate ->
>          createPopulatedList(table,prefetch,conditions,sort)

I had a discussion with Johannes the other day, where we actually got
exactly to the same point.

I think it will be good to rediscuss the API at our meeting. My goals
for the API are that it's usable, complete, systematic, easy
understandable and not bloated.

>   2. provide functions to load more then one record, and to load all
>   fields of a record:
>         geasList.loadNextInstances(maxRecords=5)
>       geasInstance.getAllFields()

I'm not sure about loading more than one Instance at a time. If calls to
the server are _really_ that expensive, I believe we have to make them
cheaper anyway.

Definitively, I'm against getAllFields. This will _kill_ performance
because we most probably don't need all fields of an object, and the
unneeded fields might be long texts or even blobs with pictures and the
likes.

> I think especially the second problem should be discussed on the
> european gnue conference in frankfurt on the 31th.

I agree 100%. That's actually the reason why I liked the idea of the
conference.

Thanks for your thoughts,
Reinhard

-- 
Reinhard Mueller
GNU Enterprise project
http://www.gnue.org

signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil