Seismogram iteration Benefits:

Client:

• Provide an intuitive interface, following the rule of least surprise. (Having a method
  called retrieveSeismograms with a preferred usage pattern of
  retrieving a single seismogram is not intuitive.)
• Provide two straightforward paths to retrieving seismograms, appropriate to
  differing needs of different clients. (Some clients will only ever retrieve a single
  seismogram at a time. For instance SOSA. Some may always retrieve groups -
  say for event analysis.)
• Provide server brokered iteration, push complexity to server
  • Assume more clients will be written than servers
  • Client doesn't need to estimate request sizes to fit server memory requirements
  • Clients can easily request large amounts of data
    Computational capabilities of desktop computing facilities have
    increased significantly, and the DMC foresees demand for large data sets
    increasing. Increase might be in length (multi-day records) or multiple
    short seismograms (such as 15 minutes from all stations within a 5 degree
    radius in the LA Basin).
  • Client can broker UI dialog with user regarding when to halt downloads, or
    generally stop when it's had enough

Server:

• Provide opportunities to optimize:
  • For seismogram data stored within files, server can retain the previous seek file
    position
  • For database driven data, server can load next chunk while waiting
  • Server can dynamically set size of chunks returned, returning larger amounts
    when loads are light
• Provide a uniform interface for all servers (disk and tape based) (but for this we'll need more info in QueueID)

Drawbacks:

• API now inconsistent between NetworkExplorer and SeismogramDC
  Since the preferred call sequence is availableData( in RequestFilterSeq filters), the
  paradigm doesn't seem too strong.
• Server writers will need to come up with defensive programming techniques to limit
  outrageous requests
• Server writing requires saving state
• Major change from DHI 1.0