Re: zOGI - lightweight response from putObject

On Tue, 2008-07-22 at 13:57 +0100, [email protected]
wrote:
> > 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. 

It should happen now if the client advertises that it supports it.  This
is the default behavior of SOPE and SOPE does all the HTTP plumbing.
Last time I checked the exchanges between CookComputing's XML-RPC.NET
assemblies and zOGI were compressed.

>  I would hope that providing the xml-rpc client 
> accepted encoding as gzip then Apache could perform that work.

Yes.

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

You do have the data, but only assuming it hasn't been changed on the
server by another user/process.   Version detection SHOULD prevent that
of course but one can disable version detection in the put in order to
force an update.  By allowing that the full response is required.   But
I am open to supporting a "short response" via a FLAG;  although I think
doing that from a fat client might invalidate the cache in some edge
cases.   I prefer a pessimistic approach to cache coherency.

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

Maybe,  but that API stinks so bad..... :)

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

I think this is a legitimate issue, but not a terribly high priority.

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

Hopefully not.  The real issue is if someone detects a version conflict
and then the user decides (in an application that supports version
conflict resolution) to force the 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. 

Right,  which is why this is a legitimate issue.  But applications may
also do requests at varying levels of detail for performance.  For
example, if you do a search in Consonance
<http://code.google.com/p/consonance/> it does the search at a very low
level - just enough to have the data to display in a list-result /
search-result widget.  The object in the cache is tagged with the detail
level it was retrieved at.  Then if a user "opens" the contact the edit
widget checks the detail level, and if it doesn't include the required
information (basically all the data) it issues an async getObjectById
request at a higher level and "greys out" ("freezes" in Consonance
parlance) the form.  When the result is received the cache is updated
with the new 'fuller' object and the widget/form/dialog "lights
up" ("thaws" in Consonance parlance) displaying the full data.  So
receiving update responses at varying levels of detail can possibly
confuse the cache (some information in the same entity may be current
and other information out-of-date) so full-response to modification
requests was chosen for simplicity.

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