perfsonar development work

["Jeff W. Boote" <>]

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