- From: Henry Story <henry.story@bblfish.net>
- Date: Sat, 18 Jul 2020 19:55:46 +0200
- To: Aaron Coburn <acoburn@apache.org>
- Cc: Melvin Carvalho <melvincarvalho@gmail.com>, Eric Jahn <eric@alexandriaconsulting.com>, LDP Next <public-ldpnext@w3.org>
> On 18 Jul 2020, at 19:50, Aaron Coburn <acoburn@apache.org> wrote: > > > Second (related to the FS analogy mentioned earlier): Solid puts a lot of emphasis on the semantics of slashes in URLs (e.g. containers always end with slashes), which means the LDP interaction model can be derived from the other parts of a request, rather than from client-supplied Link headers. This (arguably) simplifies the client-server interaction, since clients no longer need to supply explicit link headers when creating resources; the idea here is that HTTP clients already supply a request URL and Content-Type and web developers are (arguably) more familiar with those compared to link headers. This also means that, when building Solid on top of LDP, the server can accept an explicit interaction model, but if one isn't present, a server-level filter can derive one from other information in the request. And since Solid only uses basic containment, there are really only three relevant interaction models: LDP-RS, LDP-NR and LDP-BC. Solid makes no requirements on slashes. Those are given as examples, as they help make intuitive sense of the protocols, as they map nicely to file system intuitions. Clients and servers have to discover resources by following links. Henry Story https://co-operating.systems WhatsApp, Signal, Tel: +33 6 38 32 69 84 Twitter: @bblfish
Received on Saturday, 18 July 2020 17:56:02 UTC