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

[Dmitri Pal]

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?



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


-- 
Thank you,
Dmitri Pal

Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/