Re: zOGI - lightweight response from putObject

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

Right.  I couldn't see an option in the Flags to set a detail level.  If 
that could be done, then it would help. Another thing we could look at is 
the idea of gzip encoding responses.  I'm not sure how that will work with 
Apache/Sope/xml-rpc/zOGI.  I would hope that providing the xml-rpc client 
accepted encoding as gzip then Apache could perform that work.  Maybe this 
is what I really need: after all, even returning 25 contacts at a detail 
level to show email addresses is a pretty large document. Anyway, I'll add 
my thoughts to your other remarks just so I can increase my understanding.

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

Assuming the action is something like:

searchForObjects -> display -> select -> edit -> save
 
then surely the client already has the data necessary for maintaining a 
cache?  Indeed, I'm very interested in maintaining a local cache, but I 
don't see that doing that requires that putObject's response should return 
the entire object - I've already got the data for my cache from 
searchForObjects (at the very least the 'edit' action could request a full 
object and then store that in the cache).

> Obviously this probably isn't true for
> import / utility scripts,  but they aren't considered the primary use
> case. 

I'm not so much thinking of import/utility scripts (I understand that 
these might be best done using the traditional xml-rpc interface).  I'm 
thinking more of the use case where a user may want to apply an update to 
multiple entities (Tasks might be the best example here, although I can 
imagine also a situation where many contacts/enterprises may need updating 
e.g. if a dialling code changes).  Rather than edit each entity and save 
it, the entities could be selected from the displayed search results, and 
an updated applied to each of the selections as a group.  This would be a 
very slow activity if putObject returns extensive object details as a 
response.  In full honesty, I haven't actually _got_ a definite need for 
this, but just trying to imagine the possible uses limited by putObject 
returning extensive object details :-)

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

Obviously one wants to avoid 'lost updates', but if an objectId & version 
number are returned to the client, and the client anticipates that version 
number, is there really a lost update?  The 'fan out' to other attributes 
seems the most important reason.  But even here, if I am obtaining 
entities at a detail level that doesn't request those attributes, I'm not 
sure that anything is lost here. 

Bernard

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