- From: Markus Lanthaler <markus.lanthaler@gmx.net>
- Date: Mon, 9 Mar 2015 23:33:43 +0100
- To: <public-hydra@w3.org>
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" >>> 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? >> 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. > 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. >>> 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. Cheers, Markus -- Markus Lanthaler @markuslanthaler
Received on Monday, 9 March 2015 22:34:16 UTC