SODA, half-client

[James.Dempsey at csiro.au]

Hi Markus,

> -----Original Message-----
> From: dal-bounces at ivoa.net [mailto:dal-bounces at ivoa.net] On Behalf Of
> Markus Demleitner
> Sent: Monday, 11 April 2016 7:36 PM
> To: dal at ivoa.net
> Subject: Re: SODA, half-client
> 
> Hi James,
> 
> On Mon, Apr 04, 2016 at 09:54:27PM +0000, James.Dempsey at csiro.au wrote:
> [SODA endpoint not assigning names to files returned]
> > 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.
> 
> So, in principle I agree that it's a good idea to have content-disposition headers,
> and my SODA service had them until I started to pull JPEGs and PNGs from
> them -- people wanted them to be displayed in their web browsers rather than
> save them.  Rather than switching behaviour based on -- hm, media type,
> perhaps, I switched the whole thing off hoping that further complaints might
> give me more ideas what to do.
> 
> While my hope of course is that we'll have good SODA clients that people  will
> use instead of web browsers and this whole problem goes away, I suppose a
> piece "good practices" for content-disposition would be nice material either for
> a non-normative appendix to the spec or an implementation note.
> 
> Since a constant "result.fits" (which I used when I still had
> content-disposition:attacment) would only be marginally better than dlget after
> what you write: How do you generate your names?
> 

Each of our image files has a simple unique id, so we currently use that. Some examples would be 

observations-1206-image_cubes-10.fits
cutout-545-imagecube-1778.fits

However, that naming may evolve depending on feedback from the astronomers.

For the cutouts, I'm considering adding a manifest file as the naming is difficult to be meaningful (observations-492-moscov_mom1-cutout-225831_-354646.fits). So we might retain the current name and have a manifest that states the original file name and the centre ra and dec (or galactic l and b in the future).

As we only support async for SODA currently the delivery of results is defined by the UWS standard. Providing sync support will mean we will hit the same problems of providing a download or a stream, particularly for PNGs and JPEGs. We might end up having two endpoints for the two delivery types.

Cheers,
James Dempsey