[core] Adding CRUD to the core.ll interface; was Re: draft-groves-core-dynlink-02

[Michael Koster <[e-mail]>]

> On Feb 27, 2017, at 7:25 AM, Michael Koster <[e-mail]> wrote:
> 
> [MJK] Yes, I am proposing that the binding table use the core.ll interface, which is basically a collection resource that exposes core link-format. It can be identified as a binding table by using rt=core.bnd as a resource type, rather than a special interface type. I had intended to make this change when I made core.ll support create, update, and delete operations.

I am proposing to add CRUD functionality to core.ll collections, as described in section 3.4 of CoRE Interfaces, and which is consistent with the current draft of CoRE Resource Directory, section 5.4 (attached) 

   Links in the collection MAY be Read, Updated, Added, or Removed using
   the CoRE Link-Format or JSON Merge-Patch Content-Formats on the
   collection resource.  Reading links uses the GET method and returns
   an array or list containing the link-values of all selected links.
   Links may be added to the collection using POST or PATCH methods.
   Updates to links MUST use the PATCH method and MAY use query
   filtering to select links for updating.  The PATCH method on links
   MUST use the JSON Merge-Patch Content-Format (application/merge-
   patch+json) specified in [RFC7396].
Currently, core.ll only has GET defined (Table 2), but IMO there is no reason not to add the full set of methods including PATCH. THe query parameter selects one or more links for updating, and the merge-patch document is applied to each selected link.

At one point we discussed putting this into a separate document that can be referenced from both RD and CoRE Interfaces, but it seems to belong more in interfaces, where collections are described.

Is there a place I could make a pull request to for a proposed update to Section 4.1 of the CoRE Interfaces document? I am in the middle of updating the description in CoRE RD and could do this relatively quickly.

Also have some proposed tweaks to align b and lb interface definitoins with OCF, but that is a separate proposal.

Best regards,

Michael