Solid Notifications Protocol: Review notes

[timbl]

Here are a number of review notes on the notificatiom protocol document.

[timbl]

In the introduction the spec, rather than introducing the idea of notifications as novel, should mention the solid protocol uses an existing websocket based notifications system.

[timbl]

Words should be used in ways consistent with their use in normal english. There is a thing called a Subscription (or Subscription Document) which does not correspond to one subscription. It is a thing you can POST a request for a subscription to. Channel? EndPoint?

[timbl]

1.1 Overview:
The Notification spec should use solid pod authentication as part of the document access, rather than adding ts authentication step in its own workflow.

[timbl]

It must be possible early as possible (ideally when a document if fetched from a pod) to know whether the server supports change notifications. If we use a Storage Metadata Resource as the next step in discovery, then we must be able to figure out what protocol is available, and if the app wants live updates, it needs t know whether to offer a live UX to the users, without having to abandon it if a subscription request later fails.

[timbl]

Performance is important. Performance in client-server systems is limited by the number of round trips across the net. This protocol has many more round trips than the existing web socket protocol.

[timbl]

There seems to be an assumption/limitation implicit assumption that the subscription-minting endpoint is the same for every resource in the storage. That could be OK, though it wasn't true in the current/old protocol.

[timbl]

Maybe it would be good to suggest a common property of notifications themselves as a patch: the delta between the previous and updated versions. Such as an N3Patch format thing as accepted by te PATCH function of solid servers.

[timbl]

There is the question of missing discovery first step documented in #58 and at core in the Solid Protocol at solid/specification#355 .... Assuming this method goes ahead it should be coped to to this spec as informative so you can see the whole process.

[csarven]

In the introduction the spec, rather than introducing the idea of notifications as novel, should mention the solid protocol uses an existing websocket based notifications system.

The existing SOLID-WEBSOCKETS-API will be deprecated in SOLID-PROTOCOL. I don't find it particularly informative for SOLID-NOTIFICATIONS-PROTOCOL to mention SOLID-WEBSOCKETS-API in SOLID-PROTOCOL.

Words should be used in ways consistent with their use in normal english. There is a thing called a Subscription (or Subscription Document) which does not correspond to one subscription. It is a thing you can POST a request for a subscription to. Channel? EndPoint?

https://solid.github.io/notifications/protocol#subscription requires servers to support GET, HEAD, OPTIONS, POST methods targeting https://solid.github.io/notifications/protocol#subscription-resource .

1.1 Overview:
The Notification spec should use solid pod authentication as part of the document access, rather than adding ts authentication step in its own workflow.

That was the intention. Will follow up in #77 .

It must be possible early as possible (ideally when a document if fetched from a pod) to know whether the server supports change notifications. If we use a Storage Metadata Resource as the next step in discovery, then we must be able to figure out what protocol is available, and if the app wants live updates, it needs t know whether to offer a live UX to the users, without having to abandon it if a subscription request later fails.

Regardless of how/what information is obtained about requesting a particular kind of subscription, the subscription request still needs to be carried out. If an app wants to attempt to subscribe for live updates as "early as possible", it can do that by reading the subscription resource description.

Performance is important. Performance in client-server systems is limited by the number of round trips across the net. This protocol has many more round trips than the existing web socket protocol.

Will respond separately.

There seems to be an assumption/limitation implicit assumption that the subscription-minting endpoint is the same for every resource in the storage. That could be OK, though it wasn't true in the current/old protocol.

There is the question of missing discovery first step documented in #58 and at core in the Solid Protocol at solid/specification#355 .... Assuming this method goes ahead it should be coped to to this spec as informative so you can see the whole process.

It is not required. #104 describes how servers can advertise describedby (resource-centric) and solid:storageDescription (storage-centric).

Maybe it would be good to suggest a common property of notifications themselves as a patch: the delta between the previous and updated versions. Such as an N3Patch format thing as accepted by te PATCH function of solid servers.

Perhaps as a Notification Profile: #101 ?