search

solid / notifications

Solid Notifications Technical Reports
https://solid.github.io/notifications/protocol
MIT License
11 stars 7 forks source link

Solid Notifications Protocol: Review notes #76

Closed timbl closed 1 year ago

timbl commented 2 years ago

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

timbl commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

csarven commented 2 years ago

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 https://github.com/solid/notifications/issues/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. https://github.com/solid/notifications/pull/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: https://github.com/solid/notifications/issues/101 ?

csarven commented 1 year ago

Closing this issue and will follow-up on linked issues and in addition, https://github.com/solid/notifications/issues/110