Re: zogi - birthDate attribute of Contact

> I don't specifically need to use the birthDate attribute, but who knows 
> what clients might ask for ;-) 

Yes,  which is why it would be good to at least define what happens.

>  Basically, I'm trying to exercise OGO and 
> the different xml-rpc bindings to find out where things might go 
> pear-shaped. 
> I assume from what you are saying that the zOGI xml struct for other 
> entities (e.g. tasks) will also be inconsistent when it comes to empty 
> date values (i.e. that they will be outputted as string types, but expect 
> dateTime.iso8601 types? 

No, they should always be dateTime.iso8601 values.  birthDate is
different as it may or may not contain a date.  Appointments always have
start and end,  tasks always have start and due, etc... The only other
odd date value I can think of is the task's completion date since there
is not a completion date until the task is completed.  It is only the
nullable fields that present the issue and fortunately they are few.

> I'm not sure what to suggest.  As Helge intimates, using 1001-01-01 is a 
> hack, but then probably any solution to this is going to be a hack.

Yes.  The root problem is that, IMO, XML-RPC itself is a hack.  It has
numerous deficiencies - date times have no time zone (not a terrible
problem for zOGI as we just assume GMT), no null value coding,
introspection support is a joke, and everyone implements coding of
binary/arbitrary data differently enough to break.  SOAP or ICE would be
better but we are currently limited to what SOPE supports;  although
maybe SOPE supports SOAP,  I wasn't able to find any examples.  If/when
the JOPE/GETObjects port of OGo becomes available I intend to port zOGI;
we'll keep XML-RPC support and hopefully add support for other protocols
(most notably SOAP) since that should be much easier in Java [which
supports every protocol under the sun].

<aside>You really don't want to get me started on the whole topic of RPC
protocols. :)  Personally, I liked CORBA.  Every RPC project (REST,
XML-RPC, Argot, JSON, Thrift, etc...) is created because the "other"
protocol is bloated/fat/sucks.  So people busily spend time and effort
recreating the same problem only worse - they create a light & thin RPC
mechanism, then realize it doesn't work in the real world, then define a
bunch of extensions not everyone implements or everyone hacks around the
deficiencies in their own way.  But mostly they are too stuck on their
solution to finally admit that, really, stubs and/or WSDL aren't that
bad by comparison.  And if you use a decent toolkit you never have to
deal with those manually anyway.  Arghh!</aside>

Sorry. :) I spend 80% of my time on things that just move data between
applications, so this is a sensitive nerve.

>  What does OGO's original xml-rpc binding do with empty date values? 

It doesn't do anything.  A null date field from the database is just an
EONull (?) internally.  Internally OGo doesn't use XML-RPC,  XML-RPC is
just used to expose an API built around Logic.  Logic itself uses a
command-pattern model.

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