perfsonar development work

[maxim <>]

Hi Jeff,
I agree with you. Again, I dont care about what time format is supported but
I more
care that there is a type of format which is supported everywhere and
interoperable.
 I am totally ok with UNIX epoch time. Of course as soon as every
application understands that I am sending 
Unix UTC timestamp in seconds and not expecting anything else ( local
timezone, milliseconds ... etc.)???. 
 --Maxim

> -----Original Message-----
> From: Jeff W. Boote 
> [mailto:]
>  
> Sent: Wednesday, January 17, 2007 10:45 AM
> To: maxim
> Cc: 'Loukik Kudarimoti'; 'Asif, Mohammad'; 'Maciej Glowiak'; 
> 'Roman Lapacz'; 
> ;
>  'Li, Yee-Ting'; 
> 'Nicolas Simar'
> Subject: Re: [pS-dev] Problem with SQL-MA!! Support for ISO 
> timestamp format ?
> 
> maxim wrote:
> > Hi Loukik,
> > This requirement comes from my strong believe that messaging data 
> > format should be consistent throughout the whole perfSONAR 
> framework. 
> > Its really strange and confusing to support different kinds of time 
> > format under the same namespace and same schema but for different 
> > applications. If schema allows one to use ISO or Unix time 
> format then 
> > this capability must be supported everywhere. If only Unix 
> time format 
> > is supported then it should be documented and again supported 
> > everywhere. Otherwise it will create a big mess.
> > That's specifically true in service oriented environment 
> where every 
> > service should be available ant interoperable with other 
> services from 
> > the same framework.
> > Thanks,
> >          Maxim.
> 
> 
> Absolutely. This *can* be an interoperability issue.
> 
> But, it is not a requirement that all timestamp formats to 
> usable in all 
> messages. The requirement is that all clients/servers 
> understand what time 
> format is expected in the specific messages they are using to 
> exchange specific 
> data types.
> 
> For example, if you look closely at the rnc files, you will 
> notice that one of 
> the time formats is simply a monotonically increasing 
> counter. This is to 
> support something like the TSC register on a given CPU. That 
> is obviously not a 
> useful time format for the value in an RRD file. (But, it is 
> critically needed 
> for other types of data. And, in certain contexts, it is 
> possible to convert 
> that time to an ISO - But, not in all contexts.) This fairly 
> complex issue took 
> up over a year of debate in the GGF (I really don't think it 
> would be useful to 
> rehash the whole thing, but I do want to point out that the 
> current rnc layout 
> is a direct result of a LOT of thought.)
> 
> BTW. This message format interoperability issue is the main 
> reason I have been 
> pushing for very specific names for the eventType values. The 
> eventType value 
> will indicate the message format for the rest of the metadata 
> and associated 
> data. All clients and servers that expect to be able to 
> exchange a specific 
> message format, need to agree on which specific time formats 
> are appropriate for 
> specific messages.
> 
> Now, that said. I do think that it makes sense for every 
> message to support the 
> ISO format in all cases where it even remotely makes sense. 
> This should be the 
> 'fallback' format that a 'generic' client could use to 
> request data. And as 
> such, I think it should be one of the formats supported for 
> the RRD MA and SQL 
> MA messages.
> 
> jeff
> 
> P.S. Once again, this outlines the critical need for protocol 
> specification 
> documents. And, I realize I owe a message to the group 
> outlining appropriate 
> naming conventions for eventType namespaces. I will get that 
> done this week.
> 
> (I wish we had some protocol documentation framework to put 
> this in... The 
> maillist is not a good way to keep this information 
> available, and the wiki is 
> difficult to keep organized for specific reference material 
> like this.)
>