Re: zogi - birthDate attribute of Contact

> I can see that that does sound like the clean solution.  However, it may 
> make more work for me. 

Which is a bug, IMHO.  But possibly an unavoidable one.

>  My toolset does not have a xml-rpc binding, so I'm 
> just parsing out whole structs and then replacing the xml node values when 
> they have changed on the client (hence the problem if the output struct 
> format varies from the input struct format). 

Right,  but the focus is, understandably I think, on supporting use of
bindings.  I think the vast majority of situations will use a binding;
even wierdo languages like Lua have an XML-RPC binding.

> At the moment I'm just assuming that zOGI outputs the array members of a 
> struct in a deterministic order each time (certainly seems to).

If you mean "order" as in attribute A before attribute B then I
definitely think that is circumstantial and *not* a feature (like
selecting records from an RDBMS and getting them in the same order every
time - might happen, but you shouldn't count on it). 

> I'm not 
> entirely happy doing it this way (but at this stage of the development it 
> is a quick solution), as it introduces a dependency.  

It is hard to imagine how this is easier than using something like
Python, Jython, or <gag>Perl</gag>.  What are your constraints?  The
aforementioned Lua can easily be bundled to avoid creation of a
dependency.

> As my work is still in the early stages, I'm quite amenable to voting for 
> the best solution even if it does mean more work for me later :-) Whatever 
> happens, it looks to me like the output struct and the input struct are 
> not going to be isomorphic.  

You should be able to send any struct you receive from zOGI straight
back to zOGI unmodified.  That is a design principle,  if there is a
case where that doesn't work it is a bug.  This would potentially allow
a client to serialize the response to a file as a crude kind of cache.
Any read-only fields in zOGI are (or should be) simply ignored when
received.

The only specifically non-isomorphic value is the FLAGS attribute of
putObject.  This value is dropped on the response to the client.  But we
can't guarantee isomorphism from putObject anyway as you can send a bare
minimum struct to zOGI and you'll get back a much expanded response
(possibly with fields containing default values, etc...)

> Unless dates are output and input as strings.

Dates as strings would break the binding for rich type languages
(Java, .NET, etc..) and introduce a need to parse dates on the client.
That fattens the client side "wrapper",  which is against the zOGI
design philosophy.

What I'm thinking is to leave the empty string as the default behavior
since there are currently client code that deals with it.  But I can add
a flag to request MinValue on null dates.  Then .NET (and Java?) clients
just use that flag and side-step the issue.  If there is a hack required
I strongly prefer to have it performed on the server side, once, in a
consistent manner.  The purpose of flags is deal with edge cases and/or
provide meta-data about the operation anyway.  We already have:
"filter", "noCommit", "limit", "favorite", "unfavorite", and "revolve".

I'm not 100% sold on that solution either as I don't really know if it
makes things any easier - it just avoids the possibility of an invalid
type case exception.

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