SODA, half-client

[Mark Taylor]

James,

yes, that makes a lot of sense.  Since it translates to work for
Markus and not me, I'm happy to concede it's a good idea :-)

Mark

(sorry for the slow response, I was on holiday this week)

On Mon, 4 Apr 2016, James.Dempsey at csiro.au wrote:

> Hi Mark,
> 
> The main reason is for the convenience of users. In the services I have set up I have inevitably been requested to provide friendly, unique, names for downloads. The extension is helpful for windows users where it is used to determine file launch actions. Also, consider this not in the context of doing a cutout now and using it, but rather in the context of coming back in a week and seeing dlget, dlget-1, dlget-2 etc and wondering which is which.
> 
> The name currently comes from the url, but you can specify the file name as part of the download stream header, which will split it from the url. I definitely agree that it is best not to force the url to carry the filename and extension.
> 
> Cheers,
> James Dempsey
> 
> ________________________________________
> From: Mark Taylor <phmbt at bristol.ac.uk> on behalf of Mark Taylor <M.B.Taylor at bristol.ac.uk>
> Sent: Thursday, 31 March 2016 9:14 PM
> To: Dempsey, James (IM&T, Yarralumla)
> Cc: msdemlei at ari.uni-heidelberg.de; dal at ivoa.net
> Subject: RE: SODA, half-client
> 
> On Thu, 31 Mar 2016, James.Dempsey at csiro.au wrote:
> 
> > While no doubt outside the prototype UI, the downloaded file has a static name dlget. It would be useful if this had a fits extension and perhaps related back to the original image.
> 
> why?  My general position is that URLs should be treated as opaque,
> and in particular relying on file extensions is a bad idea
> (except on OSs where they are supposed to be significant, or maybe
> as a hint in absence of other information).  In this case there
> is a Content-Type: image/fits, which is where you should look.
> But if there are good reasons to disagree with that, by all means
> argue them.
> 
> Having said that: I tried using Markus's (nice) client with
> SAOImage DS9 and SkyCat/GAIA as alternative image viewer SAMP clients.
> Both failed, for reasons that I'm guessing are to do with the quite
> ugly URL
> (http://dc.zah.uni-heidelberg.de/califa/q2/dl/dlget?ID=ivo%3A%2F%2Forg.gavo.dc%2F~%3Fcalifa%2Fdatadr2%2FIC1528.V1200.rscube.fits&DEC=-7.097008036747518%20-7.089047402267772&RA=1.2644871315905835%201.2799343705069166&&&&&&&).
> However, I've filed bug reports in both cases, since I'd see that
> as a failure of the client not the service.
> 
> Mark
> 
> --
> Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
> m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/