RE: Filters as views (ISSUE-45)

On 15 Feb 2016 at 21:56, Ruben Verborgh wrote:
> We're making things too complicated.

I fully agree. I think we need to take a step back and look at this with
fresh eyes. I would like this to be closer to HTML forms than to S(PAR)QL
queries. We will need to sprinkle in some additional hints/semantics for
machine clients to understand what this "form" is doing but that should be
quite minimalistic.


[...]

> The goal is to reduce the API
> to symbols the client knows and can manipulate.
> 
> The question is: how do we choose that set?
> It should not be too complex, but not too simple either.
> Too simple means every use case is a one-off.
> Too complex means nobody will use it.
> 
> A minimal set of symbols includes for me
> at least the possibility to describe
> how a form creates a view from a collection
> for basic combinators such as AND and EQUALS.

Are you sure the EQUALS is enough?
In a lot of cases the AND can be transformed into an OR by issuing multiple
separate queries but the comparison operator can't be changed with such a
trick.


> If we can't say in Hydra that
> "this view chooses items of the collection
>  that have equal values to your input"
> than we cannot do a lot with Hydra.
> 
> If we do allow that in Hydra,
> we should make that mechanism extensible
> to support other ways of defining views in the future.
> Otherwise, it's again a one-off.

That's the point I'm struggling most with. Keeping this extensible (without
having to change most of the concepts) introduces a lot of complexity. I
haven't found an elegant way to tame that yet. Do you have any ideas in that
regard?


--
Markus Lanthaler
@markuslanthaler

Received on Tuesday, 23 February 2016 22:10:11 UTC