Replies: 3 comments 5 replies
-
So it's a standard Solid GET request to the URL of a resource, not a different URL to indicate that this behaviour is wanted? In short, how the server handles a GET request is that, after authorization and so on, a data stream is fetched from the backend, which gets piped into the HTTP response stream, causing the response to close once the data stream is finished. To keep the stream open, I think it would make most sense to ensure that the data stream does not finish once it sent out all its data. An alternative would be to not close the HTTP response stream once the data stream is finished, but that seems less feasible as that part of the code is mostly hidden away from everything else. To keep it open you would need some sort of custom stream implementation that sends out all the data from the data stream, but not the end event once it is finished. Then that stream would listen to changes on the same resource, and emit a patch event on the same stream every time that resource changes. When doing this it would have to be done in a way that the locking mechanism works with the original data stream and not the new stream as that would prevent writing to that resource during the same time and eventually cause a timeout. Another issue would be how to generate those patch events. When doing a PUT request, CSS does not first check the original data before replacing it with the new data stream. So somewhere in the process of writing data, something would have to be changed/added so it first reads out the original source and compares it to the new data that is being written, generates a patch object from that, and then adds this to the event that is emitted when a resource is updated. This would break the streaming aspect of the CSS though, as the resource would have to be loaded into memory (twice), so would potentially have a significant impact when writing large files |
Beta Was this translation helpful? Give feedback.
-
Looking at those issues, it seems I already mentioned this problem there: solid/notifications#61 (comment). So my point is the same as there. |
Beta Was this translation helpful? Give feedback.
-
I have now released Solid-PREP https://cxres.github.io/solid-prep/protocol, which defines representation and semantics for PREP notifications sent from LDP Resources on Solid Servers (identical to a SNP notification message, triggers may be a bit different from CSS). No diff/deltas are not defined, since the same is not specified yet in SNP either (though I would not mind some advice on that). With this, you should now be able to add PREP to CSS. Lemme know what you think! |
Beta Was this translation helpful? Give feedback.
-
I have proposing a new protocol called Per Resource Events (PREP) https://cxres.github.io/per-resource-events/protocol/ as a simpler (though less general) alternative to Solid Notifications Protocol (SNP) for sending notifications using HTTP. I am currently proposing it for standardization at IETF (as it is a proper HTTP extension, on the suggestion of notifications panel itself) while simultaneously proposing to use the same patch formats as SNP for RDF resources (to be aligned with solid/notifications#183 once notification-panel returns from its summer hiatus).
All that the protocol requires is that upon a GET request to a resource, after sending the usual response (with minimal modification to headers), the stream is kept open, on which updates to the resource are sent for a fixed time. Implementers are able to freely define the format and semantics for notifications (so could be JSON-LD/N3 Patch) for a type of resource and even clients can negotiate notification formats with the servers. This (RDF resources) is particularly where a CSS reference implementation could be powerful.
The purpose my opening a discussion here is explore what it would take to implement PREP in CSS (in a feature branch pending adoption). I am NOT a server developer and I will certainly need a lot of help navigating the CSS codebase to be able to contribute. But given that CSS implements GET (obviously!) and SNP already, for someone with the right expertise, I do not believe it is going to be difficult at all with relatively little work.
Thanks in advance, especially to the implementers, for their inputs!
Beta Was this translation helpful? Give feedback.
All reactions