v3

[ahdinosaur]

• replace sync permissions with async before, after, around hooks
• rename service and services to api
• change handlers to handler (rather than a list, return a single (req, res, next) => { next() } function). or support both.

[ahdinosaur]

one open question is whether it's okay if everything is based on separate (server, config) => {} closures. as in, what if your before hooks need to access the same internal variables as your methods? currently you'd attach this to the server or config object, or rely on the fact that methods are attached before permissions, but is this okay? is there a better way?

[ahdinosaur]

so... i re-wrote vas to only use basic http instead of WebSockets, because of requirements in a client project: http. i need to think about this more, might lead to a more pluggable vas, but not sure quite how yet.

[ahdinosaur]

the key to a pluggable vas:

represent multiplexed RPC as a duplex pull stream, where HTTP and WebSocket connections are duplex streams that wrap the generic ones.

in the simplest case, vas is a duplex stream that receives objects that describe method calls and sends objects that describe method call results.

things.get(123) // where things.get is an async method

translates to description:

{
  path: ['things', 'get'],
  args: [123]
}

and value:

{
  value: {
    id: 123,
    name: 'computer'
  }
}

or error:

{
  error: new Error('thing not found.')
}

in this simple case, when a method is a stream (source, sink, or duplex), the result will be that stream. this means it's not serializable, but i'm not sure the muxrpc way of representing method calls as packets over a multiplexed interface makes sense for both HTTP and WebSocket, when i think finding the common ground is key here.

[ahdinosaur]

let's be honest, in the end i want to re-write muxrpc. although in the near-term i might release a transition major version that uses only HTTP and also implements the original goals up at the top of the thread, because i'm mostly too busy with this current project that is using vas.

probably would help to really learn how muxrpc works:

• when you call muxrpc(), it creates an emitter and a duplex stream
  • the emitter is an object with the same shape as the service tree with a function for each method that calls a top-level function with normalized arguments when called
  • the stream reads calls and runs them locally, returning the arguments
  • the top-level function passed to the emitter writes the call to the stream, unless the stream is closed

TODO more notes

[ahdinosaur]

@pietgeursen began the re-write for version 3: https://github.com/ahdinosaur/vas/tree/v3. my plan is to go slow, aiming for a small and stable interface composed of many small modules, so if you feel any desire to test things as i go i'd really appreciate that. 😄

[pietgeursen]

Yeah, that sounds fun. :)

On Thu, 22 Sep 2016, 10:56 PM Mikey [email protected] wrote:

@pietgeursen https://github.com/pietgeursen began the re-write for
version 3: https://github.com/ahdinosaur/vas/tree/v3. my plan is to go
slow, aiming for a small and stable interface composed of many small
modules, so if you feel any desire to test things as i go i'd really
appreciate that. 😄

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
#14 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AKEUel-d9JB6MQc3DMKM4DgxIHjDfJvAks5qsl7tgaJpZM4JedbX
.

[ahdinosaur]

design now based on #20