Datalink Feedback VII: REQUEST

[Laurent MICHEL]

Le 14/04/2014 09:40, Markus Demleitner a écrit :
> Dear DAL,
>
> On Sun, Apr 13, 2014 at 07:34:05PM +0200, Laurent MICHEL wrote:
>> Making REQUEST either optional or removed in/from DALI requires to
>> update all other DAL protocols since they have to define (and to
>> publish?) a default REQUEST instead of generating an error when this
>> parameter is missing. The question is to decide if it worth to open
>
> Hm -- is that true?  SCS, for example, doesn't have REQUEST either,
> and nobody found it necessary to update it.  I admit it's not overly
> pretty to ignore one of DALI's regulations in a protocol moved
> forward by DAL, but frankly I can't see how that would break any
> existing standard...

Of course but assuming that a DAL service is DALI compliant, then it 
"must respond with an error if the REQUEST parameter is missing or the 
value is not recognised."
DALI 1.0

>
>> such a job just to get rid of an usefulness parameter in Datalink.
>> My opinion is that the highest priority it to complete Datalink. From
>> my point of view it is acceptable to  include the REQUEST support in
>> the DL 1.0 since making it optional after DALI 2.0 is endorsed by the
>
> ... and I think it's less ugly than introducing a mandatory parameter
> with the explicit call it's going to be dropped in the next version.

My proposition aims at keeping DL compliant with DALI without modifying it.
If we consider that compliance as not necessary, we can get rid of 
REQUEST (no regrets).
>
> And while I'm talking, let me briefly comment on two of Pat's points:
>
>> Le 11/04/2014 19:54, Patrick Dowler a écrit :
>>> As for REQUEST being harmful because of the & in the URLs, that happens
>>> whenever there are multiple query params in the URL. For the
>>> single-parametered DataLink links capability that looks like a pain (and
>>> it can be), but there are also other possible params that come into play
>>> already: RUNID, RESPONSEFORMAT, etc. And in general services take
>
> ...but I really can't see those in "data links" being passed around
> and published in papers, I have to say.  If these come to pass, I bet
> you basically all of them will just have an ID parameter.  Neither
> RUNID or RESPONSEFORMAT or much anything else make sense in such a
> setting.
>
>>> 1. Remove REQUEST entirely from DALI and this require a different path
>>> for each capability. Services that require REQUEST would not comply, so
>>> they would all have to jump a major version to support the new DALI. I
>>> guess that means DALI should also be 2.0
>>>
>>> 2. Make REQUEST optional in DALI so that services define values and
>>> require it only if they have more than one. Same versioning impact as
>>> above, plus then some specs could be RESTful (different path for each
>>> capability) and others could be RPCish (different REQUEST value per
>>> capability)... this seems like a non-option as it is either exactly like
>>> now, exactly like #1, or inconsistent between specs.
>
> First, as no services or clients are implemented against it, changing
> DALI is cheap.  That's not saying it should be done recklessly, it's
> saying DALI can't break any services (or otherwise all our current
> S-services were broken, as each has one aspect or another not
> compliant with DALI).
>
> Then, my preferred path forward would be a (possibly virtual)
> memorandum stating that mandatory REQUEST should be dropped from DALI
> in one way or another, where in Datalink we briefly mention REQUEST
> isn't required.
That is more or less what I'm proposing above when I'm talking about the 
REQUEST support for Datalink.
>
> And, IMHO off-topic to Datalink: Even though I believe changing DALI
> is comparatively cheap, I still think we should only work on a new
> version after the next round of DAL protocols is out, which I'd like
> to include an update of SCS.  I sincerely hope we'll have learned a
> few more things by then, like maybe proper geometry support and
> interaction with VO-DML.

Agree with this schedule

Bye
Laurent
>
> Cheers,
>
>          Markus
>

-- 
---- Laurent MICHEL              Tel  (33 0) 3 68 85 24 37
      Observatoire de Strasbourg  Fax  (33 0) 3 68 85 24 32
      11 Rue de l'Universite      Mail laurent.michel at astro.unistra.fr
      67000 Strasbourg (France)   Web  http://astro.u-strasbg.fr/~michel
---