Formal specification for ckan clients

[Ippo343]

Currently, the spec only defines the structure of the metadata.
However, there is no formal specification for how the client must behave with the metadata: as a result, other implementations of the client might end up implementing a different behaviour than the official client.

I propose that we formalize the desired behaviour that the clients should implement: each review of the metadata spec should also come with a specification of the expected behaviour.

[pjf]

Oh my, I shuddered at the word "official". Perhaps we can call it extant? :)

I propose that we formalize the desired behaviour that the clients should implement.

I agree with this. It makes perfect sense to say something like "a client must not allow two or more conflicting mods to be installed" when we're talking about conflicts, for example.

This is also nice because it means we can write a test suite that directly exercises the spec.

It's worth noting that a lot of things the clients do will be out of the scope of the spec. Relationship resolution, for example, can be done in numerous ways, and it would be detrimental to enforce clients to work one way or the other.

[Ippo343]

It's worth noting that a lot of things the clients do will be out of the scope of the spec.

One more reason to formalize what a client must do (and what not) in order to be officially compatible with ckan :)

Personally I would hesitate to say that a client "must not" allow conflicting mods (as this prohibits a --force option if a client wishes to implement that). Later today I will start on a first draft :)

[HebaruSan]

Sorry to be a stick in the mud, but what's the value to be provided here in practical terms? It mostly seems to me that this would create distractions rather than advancing the project...

• If such a spec was available, would the CKAN dev team then take on the role of certifying compliant clients?
  • If not, then why should anyone pay attention to it?
  • If we determine that a client isn't compliant, then so what? What consequences would that have other than creating friction with another team, if their app still "worked" in their eyes?
• Would we have to extend the spec (and debate its language) before adding enhancements?
• Does ckan.exe drift in and out of "compliance" as bugs are found and fixed?
• Is anyone actually going to write a fully featured alternative client when CKAN itself is already available? Such ideas come up from time to time (e.g., E.M.T.I. #2468), but generally go nowhere because the person proposing it just wants to be the leader while other people do all the work (the classic I'm not a coder but I have this great idea...).
• Is composing such a spec even possible? We only have one example clause so far (how to handle mod conflicts), and already there is disagreement about whether it's a valid requirement. Aren't we likely to have that exact disagreement about any possible requirement that could be put forward?

[politas]

Not likely to happen, even if it was a good idea.