support non-http resources

[jeff-zucker]

This PR makes rdflib's update-manager available to non-http fetchers that supply wac-allow and other related headers, a critical feature for apps like data-kitchen and for the local-storage part of gitter-solid.

With this PR, rdflib will now assesses the editability of a non-http response (file: etc) the same way it does with http responses - it will check the wac-allow header to see if the resource is writable/appendable, then check the accept-patch and ms-authorVia headers to see if the resource can be edited with a SPARQL patch.

Rdflib will also now write to local files the same way it does for web resources - with a fetcher.webOperation PUT. This replaces the firefox-extension specific writing. If someone wants to write in an extension, they can create a solid-rest plugin or create an alternate fetcher which does its own PUT. Either way, the actual writing belongs in the fetcher, not in rdflib.

The PR does not put anything in rdflib specific to solid-node-client or solid-rest, but it will now respect the headers they (or other alternate fetchers) send. Solid rest now checks the native file permissions and creates a wac-allow header that gives wac write/append/control if the current user has write permissions to the resource on the native file system and gives wac read permissions to both user and public if the user has read permission on the native resource.

If the user invokes a file: handler other than solid-rest/solid-node-client (or defaults to cross-fetch), there may not be any of the relevant headers. In that case, we fall back to the old method - check for triple containing "MachineEditableDocument".

Changes in this PR :

• fetcher now checks for global.solidFetcher, not just window.solidFetcher (otherwise we can't set the global fetcher in nodejs)

• fetcher now saves the metadata in headers from non-http responses

• update-manager does not fail if MachineEditableDocument is missing, it now checks for wac-allow headers and only fails if they are missing too

• update-manager now checks accept-patch and ms-authorVia headers to determine SPARQL editability of non-http resources

• update-manager now saves local files via webOperation/PUT rather than the previous firefox-extension specific method

• checks for 'file://' are replaced with checks for !http - this supports handling of any alternate protocol that supplies appropriate headers e.g. solid-rest currently supports app://

[jeff-zucker]

I have implemented all of @angelo-v 's suggestions above except adding tests. I will do that in the future.

[jeff-zucker]

I would see these as the appropriate unit tests. Am I missing any?

non-http resources                                                              
  it can use global.solidFetcher in a nodejs environment                        
  it can update a file if it has a MachineEditableDocument triple               
  it can update a file if it has Write perms in its wac-allow header            
  it refuses to update a file that lacks both MchineEditableDoc and wac-allow   
  it can update a file via SPARQL patch if its headers support it               
  it can update a file via text/n3 if its headers support it                    
  it can update a file (by putting back full store) if it lacks accept-patch     

[jeff-zucker]

@angelo-v can we merge this and I'll open a separate issue for tests. Without this merge, it is difficult to document or work on solid-node-client or data-kitchen.

[angelo-v]

Yes that's totally fine for me

[angelo-v]

So, who will merge this? I do not have the required permission. @jeff-zucker can you do it yourself? Or @timbl ?

[jeff-zucker]

No, I can't merge, @angelo-v thanks much for following up.