Handling of resources which did not go through the HTTP interface

[csarven]

Should the Solid spec say anything about handling external resources mapped to pod's storage and URI space? Similarly, resources may come or cease to exist in a storage without going through the HTTP interface. Examples: index.html is created manually, bar/ is mapped (or symlinked) under /foo/.

To what extent is this in scope and should have defined behaviours? If at all:

• Should containers list resources sharing the same path segment?
• Do these resources adhere to the same lifecycle as resources which went through the HTTP interface?
• What are the interaction models on these resources? Is there any? A default? Determine/Derived.. how?
• ..

[kjetilk]

I don't see how we can possibly enforce anything that doesn't go through the interface we are specifying.

However, we also note that container membership is just a temporarily varying membership function, based on the resources that exist at any point in time. So, if some resource emerges through other means than the interface we specify, that "other means" must update the membership function, or the server has to protect itself from emerging resources.

Since the membership function is determined at request time, it shouldn't be a big problem for e.g. file systems, since the membership function is determined by looking at the file system right then. So, if something writes to the file system by other means, it should Just Work[tm].

[kjetilk]

Thinking about this, I don't think this is something we can tackle in near future. @timbl has mentioned that there should be a spec for a file-based backend of Solid. That would end up specifying many of the things we consider implementation details in the current work.

Backend access has the potential of messing up things where we rely on side-effects, like that an ACL is deleted as a side-effect of deleting its resource. It is hard to spec this in the general case, as it has to concern itself with a lot of the things that we now consider implementation details.

That said, it becomes important that we spec emphasizing what exists at some point, and not make assumptions about materializing certain artifacts, that will make us more resilient against such problems.

[csarven]

Agreed.

A server's observable universe of resources is limited by the interactions as prescribed by the spec.

[TallTed]

This whole "rely on side-effects" thing is troublesome, especially if there are ways to interact with server-managed content without going through the server (e.g., filesystem actions on sever-managed directories/resources).

There seems to be a need for a way (a script of some sort? either scheduled a la cron, or somehow triggered by filesystem changes) to cause the side-effects to happen when (or at least, after) actions are taken outside the view of the Solid server (e.g., filesystem additions and/or deletions)...

OR there is a need to include strong warnings about all the potential ramifications of such out-of-band activities (e.g., unexpected permission and/or forbiddance due to inherited ACL).

[kjetilk]

This whole "rely on side-effects" thing is troublesome, especially if there are ways to interact with server-managed content without going through the server (e.g., filesystem actions on sever-managed directories/resources).

Yes, I agree, there are problematic sides to that...

There seems to be a need for a way (a script of some sort? either scheduled a la cron, or somehow triggered by filesystem changes) to cause the side-effects to happen when (or at least, after) actions are taken outside the view of the Solid server (e.g., filesystem additions and/or deletions)...

Yes, there is a need for such a document, but that's a different spec, I think.

OR there is a need to include strong warnings about all the potential ramifications of such out-of-band activities (e.g., unexpected permission and/or forbiddance due to inherited ACL).

Yeah, I think we need to put such warnings in red and bold in a Best Practices doc.