Simplify the hyper-sdk-rpc API

[josephmturner]

I'd like to get your feedback on an alternative way to design the rpc server. With the current design, (1) client sends pseudo-JS string in the RPC request, (2) server validates it against methods.json, then (3) server evaluates the request string and sends back the result.

Currently, rpc methods look like "sdk.getDrive(url,driveOpts).checkout(checkout).list(folder,listOpts)".

Alternatively, we could make the rpc server expose a custom API for Hyperdrive and Hyperbee. This way, we could expose a simpler rpc method (like "driveList") to do the same thing as above, which would accept the same arguments as the pseudo-JS method:

{
  method: "driveList",  // as opposed to `sdk.getDrive(...).checkout(...).list(...)`
  args: {
    url: "hyper://PUBLIC-KEY",
    driveOpts: {
      autoJoin: true,
      sparse: true
    }
    checkout: 42,
    folder: "/foo/bar/",
    listOpts: {
      recursive: false,
    }
  }
}

Then, in index.js, we'd have a bunch of methods to handle each custom API method:

async driveList ({ url, driveOpts, checkout, folder, listOpts }) {
  const drive = this.sdk.getDrive(url,driveOpts)
  const checkout = checkout ? drive.checkout(checkout) : drive
  return collect(checkout.list(folder,listOpts))
}

Here are pros of this new method (custom API):

• shorter, more readable API methods ("driveList" versus "sdk.getDrive(url,driveOpts).checkout(checkout).list(folder,listOpts)")
• easier to recover from errors (we can anticipate and handle errors that are specific to a particular method, like drive.list())
• easier to debug, since we can add debug statements in the body of a buggy method (not as easy with a parser)
• no need for methods.json

Cons:

• more verbose and opinionated hyper-sdk-rpc code (as opposed to one parser which handles all methods and properties)
• custom API may diverge from Hyperdrive/Hyperbee APIs (future design problem?)

What do you think?

[josephmturner]

With the current design, how would we handle these two scenarios:

1. Renaming files using drive.batch()

Since the Batch class isn't serializable, the client can't call batch.flush().

2. Comparing two entries using drive.compare(entryA, entryB)

Since entries aren't serializable, the client can't call drive.compare().

[josephmturner]

Another consideration is that a custom API designed around the hyperdrive.el frontend could save on roundtrip requests to the server. For example, if the frontend wants to get the contents of all hyperdrive files inside a directory, then we could design an RPC method that would accept a public key and a directory path and then return all of those file contents in a single response.

IIUC with the current design, we'd need to first run drive.list({ recursive: true }) to get the list of filepaths, then we'd need to call drive.get() on each filepath.