Do you have an example of where it's incorrect? I'm pretty sure it's the right index.html. Note that it's still very similar to the blog post.

There is no mention of the req/res flow (someone could POST to /req, expecting it to be a MPMC queue)

In the docs it seems MPMC queues should start with /queue, but it turns out that anything that's not /pubsub or /req,/res just works, so is it really needed ?

Also the doc doesn't specify that pb-method is available to get the requester's method in the request/respond protocol

Anyway those are just minor things, thanks for the service it really rocks

Thanks! Several good points.

> In the docs it seems MPMC queues should start with /queue, but it turns out that anything that's not /pubsub or /req,/res just works, so is it really needed

/req/res was developed after the initial launch, since I had the idea later. It represents the most general form of the entire concept, since you can tunnel essentially any HTTP traffic through it. The plan is to change the default protocol to /req, which is why I changed the examples to /queue, to make the transition smoother. Lately I've been going back and forth on whether it's a good idea to make the switch, since most of the time /queue is what I want, and using /req/res involves complexity that isn't really in the spirit of patchbay. But just today I decided another project I'm working on will need the full HTTP capabilities, so I think I'm going to pull the trigger on it in the next couple weeks. There are several independent implementations of the /queue-style approach, so I think it's ok for patchbay.pub to take a slightly more feature-full approach.

Thoughts?

You're right that MPMC queue is a specific case of req/res where responder doesn't switch to a channel for replying so it does make sense to switch to it; nothing will be lost. You could even use the pubsub protocol by putting a query param (pubsub=true), instead of reserving a whole path prefix just for this protocol. I'd still keep pubsub because it's still useful in the general case, especially since your initial itch to scratch, poor man's notification, is done in pubsub mode

(Side question: why use pubsub for notification ? You wouldn't want to lose the notification if no one is listening on the consumer side... but you also want to possibly send it to multiple consumers at the same time. Maybe there's space for something a bit different, like "As a producer I want to block until at least one consumer is here; if there are multpile, send to all of them")

The only concern I'd have is that in the general case of req/res there's no "easy" cli tool to parse the request headers and a potentially streaming body, so it's harder to do a 1-liner (or a 5-liner) to process the input.

Thanks for the feedback

> You're right that MPMC queue is a specific case of req/res where responder doesn't switch to a channel for replying so it does make sense to switch to it; nothing will be lost

Not quite, unfortunately. The current implementation of req/res assumes the first path segment is the responder "id", and everything after that is the path to the file on that responder. So responders will shadow things and cause potentially unintuitive behavior for users who just want an MPMC. There may be ways to mitigate that though. I haven't though it through.

> You could even use the pubsub protocol by putting a query param (pubsub=true), instead of reserving a whole path prefix just for this protocol

That's actually exactly how it worked originally. Once I started adding more protocols, I switched to the /proto/ api since it makes it clear right at the beginning of the URL how it works, whereas query params are at the end of a potentially long path. Still not 100% sure about this though. Been thinking about switching to a pb-proto={res,queue,pubsub}.

> (Side question: why use pubsub for notification ? You wouldn't want to lose the notification if no one is listening on the consumer side... but you also want to possibly send it to multiple consumers at the same time.

In practice I actually haven't been using pubsub for notifications. MPMC is almost always what I need. Since the chat example is mostly a toy, I'm really not sure pubsub is earning it's complexity cost.

I suppose pubsub is still useful for streams of events (like webhooks) where it's not necessarily a disaster if the event gets dropped, but you definitely don't want the sender piling up blocked requests.

> Maybe there's space for something a bit different, like "As a producer I want to block until at least one consumer is here; if there are multpile, send to all of them")

That's an interesting idea. You'd still need a separate protocol for it, because you have to read the entire message into memory in order to send to multiple requesters, but it could be useful for sure.

> The only concern I'd have is that in the general case of req/res there's no "easy" cli tool to parse the request headers and a potentially streaming body, so it's harder to do a 1-liner (or a 5-liner) to process the input.

Yes, it pretty much requires a real script. I'm tempted to pull it out into a completely separate thing, but it turned out that MPMC is almost completely a subset of req/res, so it felt like a lot of duplication.

Thanks for taking the time to reply!

> I suppose pubsub is still useful for streams of events (like webhooks) where it's not necessarily a disaster if the event gets dropped, but you definitely don't want the sender piling up blocked requests.

Yeah, it seems to me the semantics here is not so much pubsub but rather "at-most-once". I think that kind of things makes sense for frequent updates where you mostly care about the most recent value, so things like pings from a temp sensor or stuff like that

> You'd still need a separate protocol for it, because you have to read the entire message into memory in order to send to multiple requesters

Actually, related to the previous point, that's an at-least-once thing: if there is 1 (or multiple) consumers, send to all of them; if there is none, wait for the first one, and once the first one is connected send to it. There wouldn't be a need for much serializing in memory

Regarding req/res: it kinda feels like there's some overlap with the world of CGI, it's basically the same issue; maybe it's possible to re-use or extract some of the existing libraries ?