I am guessing the answer will be no to this, but will as any.
If we were using the HTTP API for persistent subscription, from what I can gather, the subscriber would have to poll the event store for new messages.
Is there a way we could make event store post to a URL to let subscribers know that there is a new event on the stream?
Steven
Not as of now (I have discussed implementing this in the past … if you are interested contact me off list). You could also implement this fairly easily outside of eventstore using a regular TCP subscription and building the http post yourself.
Greg,
We have a TCP service which we built for managing this, but to be honest, it’s a bit clunky (my fault, not the API’s) which is why I started having a look at the HTTP API.
Do you think a subscriber should ever initiate a connection themselves, or should it always be driven from the system publishing the events?
So if doing pushes I would make eventstore itself do the posts over to the consumer group members. It’s not a ton of work just a bit of a tricky area of code and likely needs quite a bit of testing!
Yeah, I think this would be a great feature to have on Event Store.
When we create a new persistent subscription on the UI, having a field for a url to post to.
I am guessing most people who use Event Store have to go and build some kinda delivery mechanism for their events (our own took a while, and it’s probably trying to do too much now)
Yeah, I think this would be a great feature to have on Event Store.
When we create a new persistent subscription on the UI, having a field for a url to post to.
It would probably be multiple no? 
I was thinking 1 per Group.
How would you track events delivered to multiple URL’s on a single group?
We already do it with tcp connections 
Didn’t realise that!
to be fair if implemented the way I see it you could even have mixed tcp/http “subscribers” 
if not clear the whole point of persistent subscriptions is they get acked/nacked etc, can have retries etc configured, and can be to many consumers …
This could be done with http posts as well as over tcp
Sounds very good.