RE: Why the collection?

On 10 Mar 2015 08:34, "Markus Lanthaler" <markus.lanthaler@gmx.net> wrote:
>
> On Sat, 7 Mar 2015 22:45:36, Andrew Hacking wrote:
> > For Hydra to be applicable to intelligent web applications, it needs to
> > figure out how it can support those who would ordinarily do something
> > proprietary. But Hydra wont get a look in when it prescribes collections
> > and paging in such a naive way. Others have suggested that it is better
> > Hydra says nothing and just provide the building blocks, which I
absolutely
> > support.  However even the building blocks are not there yet. I can't
> > express templates with ranges currently.
>
> Why not? The building blocks are definitely there. But you would need to
define what a range is - which is consistent which "Hydra says nothing and
just provide[s] the building blocks"

There is an open issue with respect to templates and range types. I believe
it only expressed range as distinct  members, more an enumeration of values
or "individuals". This doesn't support ranges being defined in terms of
sets of things that may be determined dynamically, nor did it appear to
allow range to be expressed for data types like integers or ordinals eg
1...987654321, or dates.

So imagine any relational attribute having its range defined in terms of
some context where the range is really just defined by a collection, eg
select a shipping option based on locality.

>
>
> >>> If you take the time to read all of the prior threads on collections
> >>> and paging
> >>
> >> looking at the threads of this year, #1 and #3 largest are about
> >> paging+collections:
> >>
> >>
http://m.whats-your.name/address/org/w/w3/public-hydra/2015/?c=999&set=page
> >>
> >> will go do that, but LIMIT and OFFSET are definitely crucial
> >>
> >> maybe missed a memo about them being axed?
> >
> > Yep it was brushed aside when the original simple serial page based
access
> > proposal was reinstated 'as the discussion has got off track'.
>
> For the moment, I would prefer to focus on the simplest possible design,
yes
>
>
> > That's fine, its a deliberate choice of the Hydra core authors to not
> > address the use cases and scenarios that need solving for modern apps.
>
> ... you can implement all the uses cases you mentioned (infinite
scrolling) with this design AFAICT. If not, why not?
>

1. RANDOM ACCESS TO COLLECTION MEMBERS BASED ON ORDINAL POSITION IN THE
ORDERED SET.

2. DYNAMIC RESPONSE/PAGE SIZE (AKA LIMIT) BASED ON VARIOUS FACTORS LIKE
VIEWPORT SIZE/ORIENTATION, MEMORY PRESSURE, LATENCY.

3. RETURNING RELATED RESOURCES IN RESPONSE PAYLOADS TO AVOID 1+N QUERIES.

>
> >>
http://m.whats-your.name/address/org/w/w3/public-hydra/2015/?set=grep&q=offset
> >>
> >> right off am seeing offset=10. ugh.. ive no idea how big my
collections are..
> >
> > The original proposal uses integers for pages and page sizes. Offset and
> > limit would similarly also be expressed as integers. Offset representing
> > the ordinal position in the collection and limit being the limit on the
> > number of items to return. It would be reasonable to return the total
count
> > in the collection meta data or a range limit in the template. I asked
about
> > how to express ranged values for templates but it seems that's also an
open
> > issue that has another naive proposal.
>
> Collaboration is much more efficient and fruitful if concrete proposals
are being made than calling designs other people came up naïve without
giving concrete reasons.

I believe I have said why the template/range proposal is naive above, which
reiterates an observation stated previously.

>
>
> > Currently Hydra is a long way from
> > being able to express what many apis already do.
>
> Fully agree with that statement - otherwise we would be done.
>
>
> >> Datetimes, strings, URIs, Integers could all be offsets
> >>
> >> LIMIT is what, Bytes of representation-size? resources? triples?
> >
> > No see explanation above.
>
> But you see where this is going, right? People will have quite different
requirements when it comes to offsets and limits. Relying on integers alone
is an oversimplification that will leave a lot of potential users in the
rain.

I disagree for the following reasons.

I interpret the notion of a collection which supports pages actually being
mathematically described as an ordered set.  Your paged design implicitly
requires an ordered set for the paging to be stable.  It makes sense at a
fundamental level to be able to index/address pages/members in an ordered
set by ordinal, not by some other property.

If you want a collection ordered on favoriteCat then that would be
specified in the collection definition and members of that collection would
be ordered and grouped into pages or accessible randomly via offset/limit
using the natural order of the favoriteCat data type. Rach member has an
ordinal position within the set.  If you want a collection ordered on
different things then each of those collections are all distinct
representations with their own stable ordering that supports navigation
using page links or offset via ordinal.

>
>
> >>> a mash up of multiple resources from multiple endpoints and services
> >>> .. what your smart phone or tablet does day in day out using JSON
based apis
> >>
> >> these apps are made by companies who have cherrypicked 3rd party
> >>  API partners, then hardcoded support for them into their apps
> >>
> >> 99% of app/site-vendors want network-effects to occur within their
sites,
> >> using their API Terms and at their whim to pull the plug or acquire
any 3rd
> >> party API-consuming service/app that is getting too popular.
> >>
> >> it is HIGHLY unlikely that these companies are goign to prioritize LDP
or
> >> Hydra to maximize unfettered reuse/remixing. they absolutely want their
> >> API/site to be a special-snowflake that we use their API-client
libraries
> >> to access.
>
> Quite a few companies (mostly smaller organizations or startups) are
suffering from this because it hinders adoption. The costs to a different
API that does exactly the same are extremely high. It benefits the big
players but hurts almost anyone else in the industry.

I don't think I've ever seen an api that does exactly the same thing.
Similar perhaps in goal but in their own ways offering distinct differences
advantages/disadvantages.

Important things become a process of standardization which even then still
results in differences and extensions or non compliance.

If there is an industry or proprietary standard smaller players will swim
downstream and go with the flow. It usually takes a number of competing
approaches before recognition that agreeing on a standard may be useful to
open up the market. Big players through that process will be minimizing
churn/damage within the new specification or just trying to stall/kill it
as much as possible depending if its perceived as a threat rather than an
opportunity.