Support for auxiliary resources and manifest (#67)

[damooo]

Summery

This PR addresses the issue #67, and issue #86 by introducing support for auxiliary resources. And thus makes changes to logical resource organization, operations, etc.

The storage system organizes resources into two distinct layers: primary and auxiliary. The two layers are complementary. The primary layer organizes resources spatially and hierarchically using containment relations, while the auxiliary layer attaches supplementary resources to each node in that hierarchy using auxiliary relations.

The auxiliary resource layer is flat. Each primary resource owns a local set of auxiliary resources. An auxiliary resource is an LWS resource that is used to provide additional information or functionality related to a unique principal primary resource. The lifetime of an auxiliary resource is bound to the lifetime of its principal resource. There MUST be a link from aux resource to it's principal resource with rel value principal, and a link from principal to it's each auxiliary resource with specialized rel value for each auxiliary relation called auxiliary rel. auxiliary rels are functional. linkset is such an auxiliary rel, and linkset resources are auxiliary resources.

Most importantly, though server can manage (like linkset), or interpret (like acl) the auxiliary resources, the client too has freedom to create auxiliary resources with any aux-rel subject to functional constraint. Thus auxiliary resources are free axis , available for client as a tool for modelling auxiliarity interoperably across servers. For example, an app can choose to persist rights-info, or data-provenanace, etc using custom auxiliary relations and content media-types. Servers need not to pre-configured to support each relation specifically.

Manifest resource.

Each primary resource has a manifest auxiliary resource. The manifest describes basic resource metadata like type, etc. and provide auxiliary member listing, and contained member listing in case of containers. This manifest resource has the media-type lws+json. This essentially generalizes the membership listings on both layers, and persists as a separate auxiliary resource. Thus also freeing containers to have arbitrary hypermedia representations. This is not forced separation, but natural generalization.

Operations:

The Create operation is changed to support creation of auxiliary members as well. At the time of creation clients provide membership link, linking it to target via either up or principal rel corresponding to containment membership or auxiliary membership. The target resource is called as patron in both cases.

This is the gist. It is a significant change. But I believe it as obvious generalization, instead of forceful feature. Request to review the model first. The grammar, etc. can be updated if the direction find some resonance. Feel free to say no.

Thanks a lot for your time and consideration.

CC: @pchampin , @acoburn

---

Preview | Diff

[kaefer3000]

I see that you copied those words from the current LWS-core, so nothing to complain about in your PR. Maybe a separate discussion is to be had what the storage system is and what is its root? The file system where the resource representations are physically located? On Windows, that is C:\?