[Request Format] Make Start Time and End Time optional arguments in Rover request

[timronan]

Both Start Time and End Time are optional arguments in IRIS availability services so these arguments should likely be optional in Rover request. Changing the request format to allow for optional End Time is especially useful for Rover daemon mode because it allows users to subscribe to live seismic streams and have the stream's repository updated each time the daemon executes.

The current version of Rover could subscribe to a live seismic stream by creating a request with an arbitrary End Time in the significant future, but a user would need an advanced understanding of Rover/IRIS Availability services to create this sort of request. It seems logical to make required Rover request parameters to mimic request parameters from the Availability services and other IRIS products.

rover retrieve request3.txt
retrieve  DEFAULT: Rover version 0.0.0 - starting retrieve
retrieve  DEFAULT: Status available at http://127.0.0.1:8000
retrieve  DEFAULT: Trying new retrieval (attempt 1 of 3)
retrieve    ERROR: 400 Client Error: Bad Request for url: http://service.iris.edu/irisws/availability/1/query
retrieve    ERROR: Will log response contents (max 10 lines) here:
retrieve    ERROR: > Error 400: bad input line: IU ANMO * LHZ 2017-01-01T00:00:00 Not of the form <network> <station> <location> <channel> [<starttime> <endtime>]
retrieve    ERROR: > More Details:
retrieve    ERROR: > java.lang.IllegalArgumentException: bad input line: IU ANMO * LHZ 2017-01-01T00:00:00 Not of the form <network> <station> <location> <channel> [<starttime> <endtime>]
retrieve    ERROR: > at edu.iris.availability.NslcDateRange.<init>(NslcDateRange.java:35)
retrieve    ERROR: > at edu.iris.availability.AvailabilityRequest.<init>(AvailabilityRequest.java:314)
retrieve    ERROR: > at edu.iris.availability.AvailabilityEndPoint.getProcessingResults(AvailabilityEndPoint.java:47)
retrieve    ERROR: > at edu.iris.wss.provider.IrisDynamicProvider.doIrisProcessing(IrisDynamicProvider.java:251)
retrieve    ERROR: > at sun.reflect.GeneratedMethodAccessor34.invoke(Unknown Source)
retrieve    ERROR: > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
retrieve    ERROR: > at java.lang.reflect.Method.invoke(Method.java:498)
retrieve    ERROR: Please pay special attention to the first lines of the message - they often contains useful information.
retrieve    ERROR: The most likely cause of this problem is that the request contains errors.  Will log request contents (max 10 lines) here:
retrieve    ERROR: > mergequality=true
retrieve    ERROR: > mergesamplerate=true
retrieve    ERROR: > IU ANMO * LHZ 2017-01-01T00:00:00
retrieve    ERROR: The request is either provided by the user or created from the user input.
retrieve    ERROR: To ensure consistency rover copies files.  To see the paths and avoid deleting temporary copies re-run the command with the --verbosity 5 and --no-delete-files options
retrieve CRITICAL: 400 Client Error: Bad Request for url: http://service.iris.edu/irisws/availability/1/query
retrieve  DEFAULT: See "rover help retrieve"

[chad-earthscope]

A related issue: for POST requests, the irisws-availability service syntax for open, aka unspecified, times is different than than for the fdsnws-station service.

The fdsnws-station service takes * wildcards in the positions for starttime and endtime to mean "open" or unspecified. Whereas the irisws-availability service does not accept * and only allows both times to be missing. It does not appear possible to specify only one time open. This has implications for rover in that the request file format should match the service input.

I prefer the flexibility and clarity of the fdsws-station syntax, and think that rover should follow that but would require changes to the irisws-availability service.

[timronan]

This enhancement may follow logic similar to Issue #36.

[timronan]

This seems like to large of an issue for the release of rover. Rover has to match the structure of the availability service, not the other way around. I am closing, it was posted with an inadequate understanding of the entire system.