On Thu, 10 Feb 2011, Nemo wrote:
> Just want to remind the keepers of the hopper that we need to
> start reporting accurate information in the return structure.
There's two issues here --
1. we need the HTTP object to be able to better deal with error cases.
Although it could be done with the IDLnetURL object, they don't
support setting the filename via Content-Disposition, so we'd have to
hack a wrapper around it. (and if we changed over, the code would
break for pre-6.4 IDL users)
2. We need to be able to throw better errors from the drms_export
routines; a quick test suggests I'm guilty of sending '200' for the
wrapper script where it tests for valid input, but we're also going to
need to modify the VSO-modified DRMS code so it'll return something we
can trap on.
(and if you're returning to the size returned ... um ... the rice
compression makes it more challenging for data being served out of the
What's actually returned from vso_get is actually part of the "ordering"
process (the VSO 'GetData' call), and currently isn't modified/update by
Right now, the only information passed back about the downloading is
passed back through the 'filenames' keyword (which gives you the path of
where the files were downloaded to, so when we rewrite filenames due to
Content-Disposition headers, you can find 'em).
Or are there other complaints about the return structure?
And does anyone else have suggestions / complaints / issues w/ the return?
(or do people even look at the return? I've been trying to figure out a
way for 'vso_get' to work as both a procedure or a function, for those who
don't need it, but the way that file parsing keeps changes between IDL
versions, I can't get it to work reliably)