Re: Why the collection?

Hi everyone.

As previously stated, I am not an expert but merely someone who'd really
like Hydra to succeed, myself still learning the intricacies of these
technologies but highly aware of their potential. As such, it saddens me to
see you giving up, Andrew. One less brain to brainstorm with is a big
loss. I think I can see where your decision comes from, though.

Perhaps a bit naively, I think a common ground can be found and a
constructive proposal can be made. I personally think that Hydra could
benefit a lot from focusing solely on the basic, universal "building
blocks" we have mentioned and speed up towards a more solid release of the
specs.

However, I also do see the value in having a common implementation for the
concept of a "collection". As that is an issue that is orthogonal (imho) to
Hydra's concerns, though, I would suggest moving all efforts in that
direction to a dedicated project, ideally building on the common platform
provided by Hydra.

My 2 cents.


On Saturday, March 7, 2015, Andrew Hacking <ahacking@gmail.com> wrote:

> 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..
> >
>


-- 

--

Jacopo Scazzosi
Developer
http://www.jacoscaz.com