Meeting minutes
Introduction & Announcements
acoburn: a few other small things after main agenda items. Any announcements?
Vote: Storage Description & CID (PR https://github.com/w3c/lws-protocol/pull/183 )
acoburn: takes current storage description with same structure and uses cid documents rather than invent lws specific things.
<Zakim> elf-pavlik, you wanted to ask if it impacts storage id ?== storage root in any way
elf-pavlik: does this impact storage vs root container id?
acoburn: Needs to be canonical url - it may need to be root or identifier of storage
elf-pavlik: like the approach
gibsonf1: a little worried about this now. If the CID has to be the root container, that might cause problems.
<elf-pavlik> as I understand we would have storage !== root container with this approach
<elf-pavlik> due to access control impact I think
gibsonf1: if the CID is the storage itself as an entity and if it needs to == root container, it would make it difficult to have multiple root containers
acoburn: yes, we need to work this out before moving on of storage vs root.
jeswr: is the cid just a describer of metadata
acoburn: this just allows us to reuse the cid structure
<Zakim> elf-pavlik, you wanted to comment on potential benefits
elf-pavlik: could be useful for webhooks , would like to explore this more
<elf-pavlik> +1 to pchampin clarification
pchampin: respond to gibsonf1 - no risk that this would force storage to be same as root container - it does not prevent storage and root container to be same but can easily be separate
dmitriz: I think its fine to separate storage from root container
<elf-pavlik> +1 to just having storage and root container separate and use CID
acoburn: given discussion, need to clarify this more before going to a vote
<gibsonf1> +1
Discussion: Auxiliary Resources next steps (PR https://github.com/w3c/lws-protocol/pull/180 ) agendabot]
<termontwouter> give me a sec
termontwouter: the idea is if you have a resource and linkset at same url can retrieve using content negotiation.
<dmitriz> +1 to what Aaron is saying - linkset via conneg will be tough, better give it its own url
acoburn: main concern is that by using content location, server could have trouble content negotating with the string. Prefer header might be a better way to do it. By reserving a type, we will necessarily restrict a server from storing a content of that media type.
<Zakim> elf-pavlik, you wanted to request a document to use as a reference (rule of thumb) for when to use media-type, profile, preference etc.
elf-pavlik: could establish a common way to do it. probably can use same approach with linkset and container with the content-type.
acoburn: Being consistent is a generally good. Maybe open an issue on this.
… we can just open the issue and continue discussion there
termontwouter: agree that container is the same problem. I agree its ideal to ask for metadata directly, not clear that using a header also specifies the format of the response as a content-type would.
profile parameter in linkset RFC
gibsonf: what is the concern about saving files
acoburn: Want to be careful about different media-types being stored. For example, specifying not storing json etc. Linksets are a niche case, but any constraints on particular media-types should have a high bar on being supported. and be very careful about this.
gibsonf1: from my perspective, the Accept content-type is what a server sends back
acoburn: example: 2 LWS servers. If implementations are saving things as files, if there is a memento version, there would be some confustion.
gibsonf1: so basically, if an impl is saving resources as direct files (bytes), there might be problems
<pchampin> I claim this is a spec issue, and I can explain why
<elf-pavlik> gibsonf1 underlying storage, filesystem, db, object storage etc. doesn't seem relevant to anything discussed here
pchampin: this is a spec problem: whenever accept media type x, it does have some implications with primary vs auxialry resources.
termontwouter: agree its a spec problem. Agree with pchampin on just using linkset type, but do not see the problem of a server saving it in a way they prefer
<Zakim> elf-pavlik, you wanted to request more snippets http headers + body in the issue
<pchampin> I agree that the 'profile' trick reduces the surface of the issue, and makes it potentially acceptable, but that's a hack :)
elf-pavlik: the memento example sounds interesting - would like to hear more on that. would like to ehar more from Erik Wilde
dmitriz: Why the general approach of switching to auxiliary resource on content negotation instead of a separate url
acoburn: Inrupt will generally use a separate url for auxiliary resource. In this group how to negotiate if using the same url.
<elf-pavlik> i don't see it as switching just supporting such approach as option/optimisation
gibsonf1: our use case has a single resource
… the client can ask for various representations
… no aux resources, just one resource
dmitriz: how do you deal with binary blobs? text encoding?
gibsonf1: our data is all RDF. Files are pointers from within the RDF
… any entity has multiple states, and the state can be serialized as a triple. Hence a tree resource
… compound resource is what some might call it
pchampin: trying to optimize on this with primary vs auxiliary resource to reduce hops. The same might apply for metadata etc, this is why the profile trick might lead to more complexity (a hack) to acoburn, for the case where primary and auxiliary resource are the same, scary that differen responses with same media type
pchampin: I thought acoburn meant that I could get different linkset responses in the same linkset media type on same uri whether or not I include the prefer header, and I would not like that
<Zakim> elf-pavlik, you wanted to clarify the text encoding question
elf-pavlik: would be good to have artifacts from conclusion of conversations. What do you mean by text encoding vs binary?
dmitriz: just curious how implementation internal saving of files. To me there is a conceptual difference between primary and auxiliary resources. For me they are completely difference. They have different access controls, different lifecycles, etc.
acoburn: I think you're right to this getting to a key question on these different resources
<pchampin> dmitriz, I agree this is conceptual difference; note that the current text *allows* some auxiliary resources to be the same as the primary resources, as an implementation choice
termontwouter: the point of the PR was about being able to implement in different ways. I don't think the prefer header spec would always return same representation with different content type
<acoburn> gibsonf: one worries was about talking about resources in this way, where we get away from HTTP talking about resources
<pchampin> termontwouter, I read RFC7240 (the return=representation.concise part) differently than you; I don't think it contradicts my earlier point, but we can take this offline
<acoburn> ... in an ideal world, we don't have aux ideas to describe first idea
<acoburn> ... there are impls that require separate resources
<termontwouter> +1 to Fred's point about resource-based terminology
<acoburn> ... in our impl architecture, all different representations can be unified under a single resource