Datalink Feedback VII: REQUEST

[Markus Demleitner]

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...

> 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.

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.

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.

Cheers,

        Markus