Description
This proposal attempts to solve #110, that is, to allow clients to start receiving notifications in a single request-response cycle (at least in the case of Streaming HTTP), while preserving the essential generality of the Solid Notifications Protocol for other channel types.
I propose that Subscription Clients, when requesting a subscription using HTTP based notification channels (specifically Streaming HTTP channel, but possibly others in the future), may request the Subscription Server to start streaming notifications immediately instead of sending back a cURL. In other words, the Subscription Server also automatically acts as a Notification Sender.
The proposal takes advantage of the fact that Subscriptions are negotiated over HTTP and notifications are sent over HTTP as well. In the case of other channels, one needs to use cURL to establish the notification channels in another protocol. Since we are not switching protocols with streaming HTTP, this step becomes optional.
This proposal will work as an optional notification feature, say, instantConnection. That is, the Subscription Service, through the Discovery mechanism, can advertise whether a given subscriptionType supports this feature, and clients can request this feature.
The response from the Subscription Server will be of the form of Notification Channel Data Model, followed by zero or more Notification Message Data Model.