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?
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/ _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
