Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 21 17:43
    csarven commented #69
  • Jan 21 16:45
    elf-pavlik commented #69
  • Jan 21 15:32
    elf-pavlik commented #140
  • Jan 21 11:59
    bblfish commented #140
  • Jan 21 11:52
    bblfish commented #140
  • Jan 20 22:35
    csarven commented #140
  • Jan 20 16:27
    elf-pavlik commented #135
  • Jan 20 16:26
    elf-pavlik opened #140
  • Jan 19 23:41
    csarven commented #69
  • Jan 19 23:40
    csarven commented #69
  • Jan 17 16:39
    jeff-zucker commented #19
  • Jan 17 10:03
    kjetilk commented #125
  • Jan 16 22:57
    kjetilk commented #85
  • Jan 16 15:30
    csarven commented #85
  • Jan 16 15:30
    csarven commented #124
  • Jan 16 14:56

    csarven on editors-draft

    Add shared slash semantics in u… Add strict hierarchy in resourc… (compare)

  • Jan 16 14:37
    kjetilk commented #124
  • Jan 16 14:30
    kjetilk commented #85
  • Jan 16 14:17
    kjetilk commented #125
  • Jan 16 13:49
    RubenVerborgh commented #125
Sarven Capadisli
@csarven
It doesn't seem to be really about index.html though is it? It just seems to be that you want to be able to read / but not necessarily its containments.
What would work right now off the shelf is setting Read on the container, and actively having policies for each resource without Read. Sounds blah.
@kjetilk Wouldn't that be Read to container and its containments?
We need 116 resolved any way. So, if a resource in a container doesn't have Read for an agent or class, the resource probably shouldn't be listed (see discussion on privacy)
Kjetil Kjernsmo
@kjetilk
@jeff-zucker @csarven No, AFAICS, it is covered by acl:accessTo: "The acl:accessTo predicate specifies which resources you're giving access to, using their exact URLs as the objects.", so if you want to allow access to just the / and not the containments, you say just that. If you want to grant access to the containments also, you need acl:default
that's my interpretation anyway, To Be Verified by Tests
and now, we have a new acronym, TBVBT ;-)
Sarven Capadisli
@csarven
I can only read that with my eyes 8)
Sarven Capadisli
@csarven
(For 116) it may mean that acl:default should be filtered based on acl:Read on each resource in the container.
Jeff Zucker
@jeff-zucker
Yes, I guess that's what happens now - set accessTo Read everyone on the container and default Read to no one on the container, then where desired, set accessTo Read on specific items in the container. Seems workable. So that would work if we want index.html world readable and nothing else in the container. But ... if index.html is a representation of the container only (i.e. can not have its own .acl), we won't be able to have a container everyone can read that has an index.html (or other representation of the container) that has a more limited audience. Not the most likely use case, I guess.
Sarven Capadisli
@csarven

I would love to stick to milestone 1 and get over this big bump. It is supposed to be a FPWD for a reason. It may not seem much from the outset but it is quite significant. All releases are significant for different reasons. CR (eg. milestone 2 -ish) is significant because we call for implementations and reports.. and so on. If it is vital to have a new date for milestone 1, sure we can bump that. I originally suggested to leave milestone 1 as is, continue working. As discussed and agreed, I'll make commits to a dev branch in sets ie. rough consensus criteria that belong together - dependent or related under discussion items will have to move to rough consensus before that. I support the idea of having smaller milestones after milestone 1.
Kjetil Kjernsmo
@kjetilk
Yeah, I think we really need to get over this bump, and I feel we will have gotten a to a good place once we have rough consensus on #85, #41 and #69
It seems we are very close, lets see what we can get done today
Sarven Capadisli
@csarven
There is no "Allow-Headers" or "Accept-Headers" type of header right? (like Access-Control-Allow-Headers)
The reason I ask if server can advertise such headers via OPTIONS. Headers like Slug is a good candidate.
Sarven Capadisli
@csarven
"Why do slugs come into my house?" -- no that's not what I'm searching for but thanks.
Justin Bingham
@justinwb
lol
Sarven Capadisli
@csarven
Well, I suppose some Advanced Pizza Server AI may be asking that question... why are these Slugs coming into my space.. oh right, some silly spec mentioned the possibility.
Kjetil Kjernsmo
@kjetilk
So, about PATCH, the advancement there seems to be tied to the progress on SPARQL Update, which is a pretty big issue
the question is how strong that tie needs to be
Sarven Capadisli
@csarven
re PATCH, yes, I think we acknowledge SPARQL Update which can be a section on its own. PATCH will refer to it as one of the mechanisms.
I think I'd like to have solid/specification#138 as an agenda item for one of the spec calls. Perhaps give it a month for everyone to review (if not already).
Sarven Capadisli
@csarven
Variability in Specs is a good read. Found it useful when working on the LDN spec. I'd like us to have a better grasp on organising the Solid specs - this is beyond spec orthogonality.
Justin Bingham
@justinwb
K just looked at issue and will take a look at https://www.w3.org/TR/spec-variability/
Sarven Capadisli
@csarven
Cool! There are related documents which are quite handy.
Sarven Capadisli
@csarven
@kjetilk @justinwb @RubenVerborgh @dmitrizagidulin Kicked off the editors-draft branch: https://github.com/solid/specification/tree/editors-draft .. DO NOT MERGE this with anything. It is intended to transition the rough consensus criteria into a proper PR. Jotting things down now.
Jordan Shurmer
@JordanShurmer
:clap:
Ruben Verborgh
@RubenVerborgh
For future reference, we might want to name such branches wip/
Sarven Capadisli
@csarven

I'm open to how we organise branches. I think that editors-draft will be an ongoing thing.. even past the recommendation release. When we make a release, we create a branch and leave that alone as a snapshot. Each release will link back previous release. I wanted to keep close to something I felt comfortable with for now - again, okay to change that. See https://github.com/w3c/ldn/branches/yours for the branches and the readme: https://github.com/w3c/ldn/ linking to live snapshots, test suite, implementation reports etc.. In the LDN case, we had the ED somewhere ( https://linkedresearch.org/ldn/ ) else.

We have the gh-pages for the live approved version. That can actually be editors-draft ( best to resolve solid/specification#8 first) or the latest release. I suppose master acts as staging. There are feature/ branches.. I'm not sure if that fits well for the specs .. or if there is that much difference from wip/ .

Kjetil Kjernsmo
@kjetilk
wip/ sounds like a good thing
we should set some branch protection rules too
I set only editors can dismiss reviews
How about "Restrict who can push to matching branches ", that sounds like a good thing to enable, at least editors
Justin Bingham
@justinwb
yeah i like wip, i use that often locally
Sarven Capadisli
@csarven
so instead of editorial-draft you'd like wip/editorial-draft ?
what else would go into wip/?
Sarven Capadisli
@csarven
err s/editorial-draft/editors-draft
Kjetil Kjernsmo
@kjetilk
@ericprud Could you please add your subset of SPARQL Update proposal to solid/query-panel#4
?
Sarven Capadisli
@csarven
Cogito ergo sum
Sarven Capadisli
@csarven
Meeting on at 1300Z. We can go over Under Discussion. Focus on DELETE and related?
Kjetil Kjernsmo
@kjetilk
:+1:
Justin Bingham
@justinwb
Kjetil Kjernsmo
@kjetilk
Justin Bingham
@justinwb
okay you guys should have a notification from two threads now
how does it behave
Jordan Shurmer
@JordanShurmer
I think they're working on adding a "your threads" sort of view. like what Slack has I guess