Add a WebSocket-based notification system

[acoburn]

The SOLID specification recommends using WebSockets for notifications, and I think this would be a good way to provide an embedded message broker for Trellis.

There are a few outstanding questions to resolve w/r/t implementation. First, SOLID suggests making websocket endpoints available on each resource. This seems like a very interesting idea, as the notifications can be scoped to a particular resource or container of resources.

1. If a websocket is initiated at resource /foo, should notifications from all contained resources be made available (i.e. recursively?) or just those that that relate to that resource/container?
2. If 1. is answered in the negative, is there a resource location where all notifications can be accessed?

[christopher-johnson]

This could be relevant:
https://github.com/solid/solid/issues/70

[acoburn]

@christopher-johnson I read through the SOLID proposal you mentioned, and there are some very good ideas there.

One part of the proposal that seems to be really useful in an LDP context is the resource-centric notion of pub-sub. The other (slightly contrasting) idea is that, rather than subscribing to resources a client subscribes with a URL template, and any notifications for resources that fit that template are passed to the client. These are pretty different approaches, and one option would be to implement both and let the developer who's wiring things together decide on which one to use.

The only problematic part of the proposal (from the perspective of Trellis) involves persistent subscriptions -- i.e. a client subscribes persistently and then retrieves notifications that occurred when the client wasn't connected. While that is certainly a very nice feature, it would change the implementation from a fairly straight-forward event notification system to a full-featured message broker. And if users want a full message broker, I think it would be better to use an existing external system that already does this very well.

This still leaves the question from above as to whether WebSockets should be purely resource-centric (only notifications for that particular resource) or based on URL templates. Given that this feature is slated for Summer 2018 on the roadmap, we have plenty of time to think about the design for this.

One big advantage to the resource-centric subscription model is that Authorization becomes transparent to a client: if you can access a resource, you can access notifications for that resource. OTOH, a URL template-based approach means that a client could (potentially) receive notifications for resources that the client does not have access to. So in that case, would one have to apply per-client WebAC rules for each notification? That seems very resource intensive.

At the moment, I am more intrigued by the resource-centric pub-sub model.

[christopher-johnson]

While that is certainly a very nice feature, it would change the implementation from a fairly straight-forward event notification system to a full-featured message broker.

RIght. I think that a message broker is necessary if persistence is a requirement. Would it be possible to delegate "exactly once semantics" to Kafka (et. al.) and then wire a KafkaConsumer into the Websocket interface? What library would you use for the websocket publisher? I noticed the the JDK incubator client has some websocket features for subscribers. Camel support is limited for websockets, AFAIK.

[christopher-johnson]

the first bit of this would be an API for user-managed topics/subscriptions?

A basic kafka implementation process could be:

1. user creates topic and event filter for resource/resource group
2. async stream processor applies filter and produces to new topic.
3. extension (camel?) consumes topic and publishes to websocket endpoint. (not clear to me how to parameterize topic selector from websocket endpoint request).

[acoburn]

The current thinking is to use the Java EE Websocket interfaces and annotations along with the Tyrus reference implementation.

[acoburn]

I would like to suggest closing this issue. WebSocket-based notifications have a lot of potential benefits, but this seems outside the scope of Trellis as an LDP server. This sort of feature could be applied as an extension module in a down-stream application, but implementing it in the Trellis repository seems unnecessary.

[ajs6f]

👍 to closing. If WebSockets takes on some new importance, we can always revisit.