Solid-Rest-2.0.0

[jeff-zucker]

@bourgeoa , @Otto-AA , @CxRes, - I have followed some of each of your advices and completely rewritten solid-rest from the ground up. I need to do another re-factor in the future to make it typescript but this version moves from cjs to esm, modulerizes everything, gets rid of the horrid param passing of options, and other improvements. The new version is in the repo-cleanup branch.

Some of the big changes : it no longer handles multiple plugins - each solid-rest instance handles only one plugin and one kind of fetch, leaving the protocol switching to libraries above it like solid-node-client.

The logic is vastly improved. It first checks the request and then, if the request doesn't have errors, it checks the requested item and only if that doesn't have errors does it actually try to carry out the request. This means that we can apply most of the logic at the top rather than inside each action. So a request with a trailing slash on a slug can be rejected before even looking at the requested item. Things like attempt to patch non-RDF can be rejected by looking at the requestedItem without even touching the patch method. This makes the logic very clear (see handleRequest.js) which, AFAIK, implements close to all of the Solid spec logic in under 70 lines.

The other big change is I want users to import the plugin, not solid-rest. So new SolidRestFile() rather than new Rest( new SolidRestFile() ). This means that a SolidRest plugin that doesn't use the file-system doesn't need to import 'fs' and will make things cleaner for downstream libraries and apps.

I have not yet re-factored Mem (what used to be called localStorage) or BrowserFS. I have a new plugin due out this week Solid-Rest-Ssh (yes, you can ssh to any bash-like shell from solid-rest and treat it as a serverless pod). My intention is to keep the plugins in the same github repo (in a plugins folder) but have each of them be its own npm package. I am a bit confused if this would work in practice - wouldn't it mean that the user would have to install a solid-rest in each plugin's own node-modules space? Or maybe import solid-rest into the pugin with import(../core) or something. Thoughts welcomed.

In solid-rest-file, I've made an attempt at JSDoc but if anyone of you have some tips about it, let me know.

The only tests not passing are two text/n3 patch tests. SPARQL patch works great.

[jeff-zucker]

The other major change is that all calls to the storage plugin are located in performRequestedMethod.js.

[jeff-zucker]

Here is my current thinking of npm package structure:

@solid-rest/                                                                     
  core                                                                          
  server                                                                        
  file                                                                          
  ssh                                                                           
  mem                                                                           
  bfs    

• @solid-rest/core does not depend on any of the @solid-rest packages
• each @solid-rest plugin depends on @solid-rest/core
• @solid-rest/server depends on all of the @solid-rest packages

[jeff-zucker]

Oh yes, BTW, forgot to mention, Solid-Rest-Server works! It is an http server that serves whatever solid-rest can access.