[IGS-DCWG-47] Re: [IGS-DCWG-46] Proposal for improving IGS data flow

[Dave Stowers]

******************************************************************************
IGS-DCWG Mail      21 Jul 11:28:37 PDT 2006      Message Number 47
******************************************************************************

Author: Dave Stowers

It is good to see that the proposed data flow improvement has been
clarified and somewhat simplified (at least from my perspective). The
main points I see that remain have to do with the selection of upstream
content recipients and the definition of how to handle user notification
of replacement files.

Pre-picking recipients. (Menu? yes. Static assignment? no):

I continue to fail to see why it appears to be necessary to pre-select a
primary and backup -upstream- recipient. For example, if two GDC's are
down, should not an RDC be allowed to send a file via primary and backup
"channels" to the others that remain functional (thereby washing the
RDC's hands of further local queuing responsibility, and ensuring
maximum distribution with comparatively low latency)? I certainly
understand the need for a hierarchy, such that what is "upstream" and
"downstream" is well defined (to avoid loops). Perhaps there is a point
I am not understanding...

Replacement file notification:

The suggestion of logging (at each DC level) the receipt of replacement
files, I believe, should be the -absolute- minimum required (next is
how-to? and what to do with them?). 

Standardization (name/content), access, and location remain questions;
e.g. (as a point of conversation), should DC's that are lower than GDC's
in the stream hierarchy push their replacement logs at EOD "upstream"
also? 

Only the modifier (at whatever "stream" level) of a data file can be
responsible for providing the replacement rationale (whether a COMMENT
line in a RINEX file or a standardized accompaniment file); upstream
recipients should not be required to make this determination, but
logging could incorporate such info if easily parsed and reasonably
defined.

Replaced files?

I would not expect that the volume of replaced files would be
significant, and would propose that no cut off window be necessary or
required. I do not propose a naming convention or directory structure
for storing the replaced files, but this should not be difficult and I
can submit one if there is interest.

I look forward to counterpoint or additional commentary.

-dave