Re: Pagination (ISSUE-42)

On Mon, Feb 16, 2015 at 6:08 PM, Dietrich Schulten <ds@escalon.de> wrote:

> Hi,
>
> Am 15.02.2015 um 17:37 schrieb Andrew Hacking:
> >
> >
> > On Mon, Feb 16, 2015 at 12:19 AM, Tomasz Pluskiewicz <tomasz@t-code.pl
> > <mailto:tomasz@t-code.pl>> wrote:
> >
> > I hope I am wrong, but it is starting to look like Hydra can't really
> > offer anything reasonable that I can use in modern applications without
> > having to break out of it and just do what I do already.
>
> Or stay on the list and help form something useful :)
>
> Yes, hence hanging in there. I have around 24 years of working with
protocols and implementing standards, but I've got to a point where I've
'seen it all before'.  Same problems repeating over and over in each new
paradigm.



> Like you, I am not coming from a Linked-Data background and had my share
> of WTF moments with the difficulties you face if you embrace the simple
> idea that every JSON attribute gets its own URI.
>
>
I don't mind attributes having definitions/semantics but RDF was something
I watched from a distance and watched, and watched go nowhere. RDF/XML was
a disaster and TPF servers seem like an experiment that hasn't actually
worked. I don't want to deploy a TPF server, I want to deploy reliable
systems backing onto sql databases.  I feel the baggage RDF carries is
unrecoverable and I don't want my own API efforts requiring my teams
proficiency in that universe.  I realize its a very negative view, but RDF
to date has been a failure and the world at large continues to and will
continue to ignore it.  I can read a one pager on how to use a google api
and get up and running, I can't have a team member even begin with this
stuff without a huge cognitive investment. Whilst I am ok to do that I
expect very few web developers to make that kind of investment and grok
JSON-LD / Hydra / RDF in the minutes they can be productive reading say
https://developers.google.com/google-apps/tasks/v1/reference/  and by
inference duplicating that kind of approach for apis developed by the team.

It seems JSON-LD was an effort standing against the tide of RDF to create
something that doesn't require 10 years of RDF experience and I'd like
things to continue in that direction, but Hydra seems to be dragging things
back into RDF land by importing alien RDF concepts and vocabs. I guess I am
wanting something that doesn't require developers to digest so much stuff.


> The hypermedia returned from a single api endpoint is not the full
> > application context, it cannot provide all the valid transitions for
> > my application yet we keep pursuing this approach like its the
> > early1990s.  I think the sooner people realize this, the sooner we
> > can all move on and design interoperability standards that work well
> > for real world intelligent clients
>
> On that we disagree. But that discussion belongs to a different thread
> than pagination or maybe even a different group. Are you aware of [1].
>
> Thanks for the link.

I do however think it is relevant to the discussion here and has certainly
influenced the collection/paging design proposals.

I don't want to see next/prev/first/last transition links in payloads when
its not relevant to what a modern app needs. Its a by-product of the belief
that hypermedia drives application state.  That may be true in a
rudimentary generic client like the Hydra console that navigates a single
collection or resource at a time, and does minimal processing from payload
to view, but in a typical modern client this stuff is legacy baggage for a
paradigm that is not actually true. Random access to collection "pages" is
a requirement in rich clients yet the proposals ignores it in favor of a
paradigm of serially traversing next page ... next page from the 1990s. The
kind of app you have on your phone or tablet, or a "single page
application" built using any of the popular javascript frameworks that
provides "infinite scrolling" works best with random access to collections,
it cares not about transitioning the application state to a "new page"
based on first/last/next/prev links the collection provides as that
collection is just one of hundreds or thousands that compose the
application state. The client is firmly in control of the transitions it
will take (which are not even knowable or describable from the perspective
of a resource) when application state composed of hundreds or thousands of
resources from potentially many different services.  It is NOT the resource
driving application state transitions, the tail doesn't wag the dog,
although in the internet of the 1990s and a generic client like the hydra
console that certainly is the case, BUT is that the use case Hydra is being
designed for? If so, then I am sorry for the noise as I've been mistaken.

Regards,


Best regards,
> Dietrich
>
> [1] https://groups.google.com/forum/#!forum/hypermedia-web
>
>