DNR User experience

Who are our audiences?

• recreational users (fishermen, wind surfers, etc)
• navigational users (COE, ship pilots, surveyors, etc.)
• researchers (primarily students and modelers)

What are our products?

Who are we and who do we want to be?

Remote data collection systems

Note that these are distinct from the mirrored systems mentioned below.

Principles

• The remote systems are just another data collection platform
• the remote system should have an entry in the station attributes table
• the program in ~pobot/bin/ that does data collection at the site should be named demon.ABBR and should name its files ABBR-YYYYjjj?.eee where ABBR is the abbreviation in the attribute table for the remote system.

Mirror systems

Currently we have several remote systems that sychronize with lighthouse. However, their synchronization is very limited. "Data" is sync'ed once an hour and "software" is sync'ed once a day but dnrattr.dat isn't sync'ed and the smcorr table isn't sync'ed. This causes newer data imports to sometimes fail as the local station attributes may have changed.

How should this information be sync'ed? Ideas:

• modify the clerk to recognize files named dnrattr.dat and smcorr.dat such that they are not archived like the other files, but they are "imported" in some fashion.
• These files need to belong to pharosdb so maybe pharosdb should have some sort of import mechanism independent of the clerk?
• Just rsync these files like everthing else and run a special program that takes care of updating the database from these files.

When we use rsync there is the problem that when we compress older files in the archive locally, those files are new to rsync and so copied to the mirror. This results in 2 copies of the same data.

Should we continue to use rsync?

Principles

• never synchronize software - We're continually updating the software to take advantage of newer features. Sometimes these newer features may not be available on the mirror system. For instance, the newer perls allow the use of lexical filehandle whereas older perls do not.
• Every time we install a mirror, we should create a tag for that install in the SVN repository. This tag may become obsolete as we update the mirror system software.
• Each mirror should also have a copy of the SVN repository (at least that part of the repository that it uses: pobot, clerk, pharosdb, voiceinfo)

Unanswered questions

• How do we update the OS on mirror systems?
• How often to we update the OS on mirror systems?
  • A possible answer to this is to update the mirror everytime we update lighthouse