Re: zOGI - lightweight response from putObject

> When an object has considerable version history, it seems excessive that 
> putObject should always return such a lengthy response.  Sometimes the 
> response is e.g. 170k just to confirm that an object was saved.  

Due to the _LOGS key;  yes, it can get rather excessive.  I'm in
agreement there.  My preferred solution would be to just return the log
entries for the last 30/60/90 days but Logic [I believe] currently just
returns all the logs so I haven't implemented that.

One simple fix would be to have a default that disables LOGS in the
putObject response (detail level 65503; 65535 - 32).

> The only 
> reason I can think for returning the whole object (including it's version 
> history) is to enable a client to see that the latest addition to the 
> object version conforms to what the client just did.  

No, it is to refresh the clients cache - zOGI assumes the client is
maintaining some kind of cache.  Obviously this probably isn't true for
import / utility scripts,  but they aren't considered the primary use
case.  Remember that you may not be the only active write and
alterations to the server may have fan-out effect changing more than the
directly modified attributes.

> Would it be a bad 
> idea to return just a lightweight confirmation (e.g. objectId, version 
> number, last entry from the version history [or even last few entries from 
> the version history]? 

I'd prefer to just either restrict or disable the _LOGS key.  We see the
same problem as we have objects that have been modified hundreds of
times.

> As it is, the behaviour makes e.g. batch updating of entities from the 
> client unacceptable, principally because of the size and complexity of the 
> putObject response.  I'm particularly concerned about this for clients 
> working in a WAN environment with (relatively) slow connections. 

Correct.

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