Re: Why the collection?

Carmen,

Appreciate you going back through some of the threads.

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.

More comments inline...

On 7 Mar 2015 22:03, "carmen" <_@whats-your.name> wrote:
>
> > 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'.

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.

This is why I have arrived at the only possible conclusion. Hydra is about
supporting dumb clients like the hydra console, with dumb transition's not
what most people need with intelligent/rich clients and which represent the
majority of the applications we all use today.

will have to read these also:
>
>
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. Currently Hydra is a long way from
being able to express what many apis already do.

> Datetimes, strings, URIs, Integers could all be offsets
>
> LIMIT is what, Bytes of representation-size? resources? triples?
>

No see explanation above.

> > 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.
>
> most anyone here knows this and i'm sure you do as well, reiterating re :
>
> > one reason why an ill fitting standard to be like Hydra will be ignored
>
> Hydra could have a place for "Guerilla" description of APIs, coupled with
related URI-template specs,
>
> hopefully Hydra will be able to describe what exists, rather than
prescribe stuff most sites will never even use or hear about
>
> as for offsets, they might not always be in ?query-string
>
> http://blog.wordpress.com/page/2/ is in the URI..
>