Meeting minutes
Introduction & announcements
acoburn: one announcement...next Monday holiday in the USA
… ask the question whether we should go ahead with a meeting....or cancel
<TallTed> +0 (I won't be in attendance, but won't block others meeting without me)
<uvdsl> No strong opinion here
laurens: im fine either way
Issue triage
acoburn: we're going ot time box to 10 mins or less
… lws issue #24 my recommendation to having separate binding...is to merge
<gb> Issue 24 Reasons for separate rest bindings (by jeswr)
acoburn: if people disagree, then to weigh in
uvdsl: would second your recommendation
acoburn: please weigh in if you have opinions on any of the items
acoburn: You added this. This is, um ... This has to do with recursive. container deletion, virtual resources, and such. I think this is going to have to be clarified as part of.
laurens: i will
acoburn: Um, particularly the authorization suites and. references to ACLs. Um, I think this person's making a good point here. Um, we should ... Discuss and clarify what is going on with this, so ... let me add needs discussion.
… this one here, it ... Seems to me like this is ... a, um ... Uh, about not changing. Things significantly, the specification, but clarifying. And making things consistent, especially with regard to how resource identifiers are explained.
… Erich Bremer take special look as they relate to CRUD
lws issue#73
<gb> Issue 73 not found
<gb> Issue 73 Scalability and implementation concerns regarding permission-based filtering (by wkerckho)
laurens: Just to quickly add that the current proposal assumes that if one has read access to a container, they can see the contents of that container regardless of the permissions of the resources that are contained within. I think it brings a lot of complexity to do it the other way around, but this is something we can discuss in the context of
the container proposal.
acoburn: lws #74
<gb> Issue 74 Does Authorization Server need to get user consent again for resource authorization grant? (by damooo)
Containment: paging
laurens: you should be able to see my screen I hope
… a lot of discussion on pagination...
… ive prepared some slides (link?)
… two options. linked based schema or client-specificed interface
… Or pagination, with more control for client applications to vary parameters like the size of a page, or to traverse through the collection. And then, lastly, we have some common pagination mechanisms regarding that explicit client interface that we might want to consider here. Um, so basically what is pagination? It's dividing a large collection
of items into subsets, which we will call pages.
<Zakim> acoburn, you wanted to ask about agreement on core purpose
acoburn: is there actually agreement on that core purpose?
gibsonf1: should all be the same approach..
acoburn: before discussing approach, we need to define purpose
tallted: devling in to purpose is premature...
… we need some sort of short list of problems if you lack pagination
<gb> Discussion 10 Use Cases for Search and Indexing (by jeff-zucker)
<uvdsl> Do we have documented LWS UCs that require pagination?
tallted: (lists multiple problems) it's a big space and people are coming to it from different places....
… dont refer to in windows terms, they talk about offsets and counts...
… lastly, there is a beig challenge in the space were in because we are largely not completely bound to HTTP
acoburn: what you described, I've encountered as well, and im sure others have well
… we have use cases that touch upon this
… Ted, if you can add some of your commentary to the use cases
<acoburn> @tallted this may be the best use case, though it's not specific to containers: w3c/
<gb> Issue 103 [UC] Pagination, filtering and ordering (by srosset81) [triage] [usecase]
gibsonf1: complaint about arbitrary unit called a page...
… I dont see how this notion of a page benefits us
… convert the page into an actual request
laurens: there are examples of pagination working at scale
<TallTed> Some prior art: https://
laurens: typically offset limit-based
… i dont think the the notion of a page should be server-imposed
… basically choose the properties of the pagination scheme
acoburn: Laurens, I like your 3 separate sections
… we made only decide as a group that we only care about one of those...
<TallTed> closely related: https://
acoburn: but a page is justa subset. I do think we need some clear defintions, but a page is really just a subset of a collection
tallted: may be old news...those three things you're talking about are closely related to ACID
… this is an extremely challenging space of work
… reinventing it is going to be painful and will take us a lot of time
… should build on shoulders of giants and not try to do it again
laurens: opaque based or client-specified?
… to do this withing the timeframe of the wg
… current is based on opaque link-based traversal scheme...
… givens us flexibility, servers can choose the algo they want...the client doesnt necessarily change anything
… explicity client interface...there is prior art...like http range headers
… or using conventions of query parameters like offset and limit
… is it desirable for us to define both?
… we will want to tread carefully on
acoburn: its true http range requests allows users to define other than bytes
… if we define something else, would be novel
… other systems have used other header units...not used in a specification though
laurens: (turns slide deck over to acoburn) until laurens leaves
<TallTed> Can we get a link to Laurens' deck (or a copy)?
laurens: That's good. So, the slide here lists some common explicit pagination mechanisms that are found. One of them would be cursor-based, so using an opaque token. which, has some properties that might be desirable, having a graceful handling of inserts and deletes, working with indexes.
acoburn: if using hypermedia controls, next, previous, all of these mechanisms are possible
… snapshot based is nice if you need consistency
… collections are changing....talking about changing collections
… with snapshot you need copy on write and is not trivial
… third one, offset/limit easiest to implement, but as you are progressing, will encounter duplicates and skips.
… doesnt occur in the other three
… most of these require stable keys in order to do efficiently
tallted: again, reinventing the database world
… what you were just talking about is isolation...
… the client needs to know what isolation they need...the server might not be able to grant it
… may needs to maintain 7 copies of a 1TB dataset if server knows how to break things down...
… implementing this is non-trivial, talking about it is non-trivial
acoburn: S3 is an example of a large scale software that has a pagination mechanism
… 2 approaches S3 provides is cursor-basedd and key/seek/items
acoburn: need to decide, and echo teds point, this is a non-trivial feature
… if we don't get consensus, it will get bumped to a WG note or drop it entirely
… where do people stand on this?
tallted: one more piece of DB experience, these questions do not have universal answers....
… ODBC and JDBC have DB agnostic client connection mechanisms
… the generic API into the database-specific API
… DB isolation is something that you can specify
… see every change that every other client is making or I just want to see
… how big is the thing that you';re working on and is it really an atom?
… transaction atomicity as either the whole transaction succeeds or it fails
<Zakim> gibsonf, you wanted to ask about LDP Paging
gibsonf1: on prior art LDP paging spec un-implementable
… nothing I would know how to do
… I was unable to make it work
acoburn: what specifically? I've implemented parts of it which were fine
<acoburn> Linked Data Paging: https://
gibsonf1: i would have to look into again, there were a few issues that made it not possible
tallted: I was in LDP, it fell into a note partly because we didn't have good ways to
… bluntly, we ran out of time
… not aware of any specific implementations that succeeded
acoburn: i havent done LDP paging over LDP resources
… because solid doesn't, weve never done that
… straw poll opaque versus client UI
bendm: when you mentioned S3, how do they fall?
<ericP> +1 to opaque links + service desc to describe extensions (e.g. random-access paging)
acoburn: S3 API is a bit different
… theyre using a cursor and a key set
… its a piece of software and not a specification
<TallTed> +0 (I strongly advise making both available. Possibly one could be a MUST, and the other a SHOULD. I would not advise making either a MAY.)
<uvdsl> +-0, I do not have any implementation experience with paging. I am also unsure about the corresponding LWS UCs - UCs may inform a direction here as well?
luke: clarification - is the opaque insensitive to multiple people using it, multi user effect like acid-type between either of these?
<TallTed> I do not think there's anything blocking implementing/supporting both.
acoburn: if our remit is to define a link header with a rel=next, that is what I mean by opaque headers
… with client, a particular parameter in this case P
<gibsonf1> maybe paging is beyond scope after all
<TallTed> s/talltred/tallted/g