[Freeipa-devel] GeneralizedTime v.s datetime.datetime in XMLRPC

[Jason Gerard DeRose]

On Thu, 2009-11-05 at 10:24 -0500, Dmitri Pal wrote:
> Jason Gerard DeRose wrote:
> > On Wed, 2009-11-04 at 20:29 -0500, Dmitri Pal wrote:
> >   
> >> Rob, is it a big problem to do it right?
> >> It seems like we are cutting corners a bit and I understand why but my
> >> general experience tells me that these things are just time bombs
> >> waiting to explode.
> >> Do we really want to leave them there or we should clean it up before we
> >> release?
> >> I know it is more work but these things just do not smell right...
> >> Is there any argument against following XMLRPC standards?
> >> How much would it take to make the changes and who would be the right
> >> person to do them?
> >>     
> >
> > I've been toying a bit with a replacement for the xmlrpclib.dumps()
> > loads() functions, which leave quite a bit to be desired, especially
> > with regard to their magic guessing as to whether an str is character
> > data or binary data.
> >
> > It wouldn't be much work to replace these two functions, especially as
> > ipalib strictly uses `str` for binary data, `unicode` for decoded
> > character data (I did this because it's the "right thing to do" and it
> > allows us to gracefully transition to Python 3 when the times comes).
> >
> > As I've already daydreamed through the design issues, I bet I could do
> > it in 3 days.
> >
> >   
> 
> It seems to be related but not exactly the same thing that was discussed
> about GeneralizedTime.
> So is it something that can be refactored if we have time after we have
> a UI that people can test?

Yes, this can be deferred till a better time.  What we have works okay
for now.

> >> John Dennis wrote:
> >>     
> >>> On 11/04/2009 03:52 PM, Rob Crittenden wrote:
> >>>       
> >>>> John Dennis wrote:
> >>>>         
> >>>>> In parameters.py we define a GeneralizedTime object to be used as an
> >>>>> XMLRPC parameter. Why?
> >>>>>           
> >>>> GeneralizedTime isn't defined as an XML-RPC paramter, just an IPA one
> >>>> and XML-RPC just comes along for the ride. We only needed support for
> >>>> RFC 4517.
> >>>>         
> >>> Exactly, that's the problem. GeneralizedTime is not known to anybody
> >>> who speaks XMLRPC, but iso8601 is known to anybody who does speak
> >>> XMLRPC, and since GeneralizedTime is a subset of iso8601 anybody
> >>> requiring GeneralizeTime can convert to GeneralizedTime from iso8601.
> >>> Whenever possible we should stay within the definitions of the
> >>> specifications, since XMLRPC already has a type for iso8601 there is
> >>> no need to introduce a private type into XMLRPC which would be known
> >>> only to select parties.
> >>>
> >>>       
> >>>>> * XMLRPC defines the dateTime.iso8601 parameter value type for passing
> >>>>> date/time information
> >>>>>
> >>>>> * Python has good support for date/time processing in it's datetime
> >>>>> module
> >>>>>
> >>>>> * Python's xmlrpclib supports both xmlrpclib.DateTime and
> >>>>> datetime.datetime objects.
> >>>>>
> >>>>> * Python's xmlrpclib can be configured to use datetime.datetime
> >>>>> objects intead of xmlrpclib.DateTime objects if you pass
> >>>>> use_datetime=True when invoking xmlrpclib.loads(), however we don't do
> >>>>> that. Why?
> >>>>>           
> >>>> Never needed dates.
> >>>>         
> >>> This has nothing to do with needing dates, rather it's an issue of
> >>> which date/time object xmlrpclib will use. xmlrpclib apparently was
> >>> written prior to the introduction of datetime.datetime so it created
> >>> its own date/time type called DateTime. The introduction of
> >>> datetime.datetime should supersede xmlrpclib.DateTime but it was left
> >>> as the default for backwards compatibility. We have no need for that
> >>> backward compatibility, we should be representing date/time
> >>> information in Python's native datetime.datetime object.
> >>>
> >>>       
> >>>>> * ISO 8601 is an internet standard for passing date time information
> >>>>> between cooperating network entities. However GeneralizedTime is only
> >>>>> valid in a subset of binary protocols (primarily LDAP and PKI)
> >>>>>           
> >>>> And it is LDAP we end up speaking.
> >>>>         
> >>> No, our API is not speaking native LDAP, we're providing an
> >>> abstraction layer over LDAP.
> >>>
> >>>       
> >>>>> Given that ISO 8601 is the preferred standard, that's it is directly
> >>>>> supported by XMLRPC, is compatible with datetime.datetime and the fact
> >>>>> datetime.datetime has excellent support in Python shouldn't we be
> >>>>> using datetime.datetime for all our date/time information and only
> >>>>> convert to and from GeneralizedTime for the subset of interfaces which
> >>>>> require GeneralizedTime?
> >>>>>
> >>>>>           
> >>>> This could always be revisited but at the time we didn't need full-blown
> >>>> support and in fact don't want timezone information.
> >>>>         
> >>> datetime.datetime can be use with and without timezone information. We
> >>> probably want to establish a convention that all date/time information
> >>> is exchanged in UTC (effectively the same thing as omitting timezone
> >>> information, if that's what you meant). datetime.datetime handles UTC
> >>> trivially.
> >>>
> >>>       
> >>     
> >
> >   
> 
>