Re: [dev-groupware] Java OpenGroupware API - EarlyAccess Release
Helge Hess <[email protected]>
| Newsgroups | gmane.comp.cms.opengroupware.xmlrpc.devel |
|---|---|
| Message-ID | <[email protected]> |
... moved to xmlrpc@ogo ... On Freitag, Aug 29, 2003, at 23:08 Europe/Berlin, Andreas Rath wrote: >> Gesendet: Freitag, 29. August 2003 19:44, Helge Hess wrote: Maybe I >> This could either mean introducing something like a "PersonFragment" >> object (like there are DocumentFragments in DOM) in the JOGI API or >> just use XML-RPC directly in the "target" API since full document >> objects are not required anyway. > > In the JOGI API, when something was changed for example the lastname of > a person in the person document, we are sending "person.update" with > the > whole person document. There is some need to refactoring. Well, thats actually not a particulary big problem in practice and more the category "nice to have". > I thought about checking, what has been changed and then just sending > these things to the XML-RPC Server that have to be updated. Yes, this would be nice, but wouldn't really boost performance. Well, maybe you could track whether addresses changed prior submitting them, that may give some speed. > But before we are going to optimize our API we have to make sure that > we > are covering almost every functionality provided by the XML-RPC OGO > Server. My points are not related to "optimization" at all. I just wanted to bring up some issues which need to be thought about *prior* fixing an API. Eg another thing which might look convenient in the first place but is likely to become a problem in the long run, is returning fetch results as a List or Vector. Something like "fetchPerson" should always return an enumerator so that the API doesn't require to load the whole database in advance. regards, Helge -- OpenGroupware.org - http://www.opengroupware.org -- OpenGroupware.org XML-RPC [email protected] http://mail.opengroupware.org/mailman/listinfo/xmlrpc