Improve the Adapter API for CRUD

[Yoric]

Now that we have some experience building an Adapter for a CRUD, let's see what we can improve.

Ping @fabricedesre, @mcav, @dhylands, @azasypkin .

[Yoric]

My impression, based on @mcav's code, is that the following architecture works nicely:

• the adapter provides a Setter for creating (e.g. taking a new picture, adding a new rule, etc.);
• each entry in the CRUD is a Service, which can have one Getter for Read, one Setter for Update, one Setter for Delete;
• we use the Service's PropertyBag to store the creation date, the file name, etc;
• we use a tag to somehow specify to which device the Service belongs.

The main advantage of this is that this already works, without having to complicate the API or data structures, and that we already have primitives for watching the list of entries, accessing them, etc.

[mcav]

While the approach I took in Thinkerbell's adapter does work, the "one setter each for get, set, and delete" idiom seems overly complex. In practice, I think it'd make more sense to invert the structure: allow services to expose a "channel" that can respond to GET/SET/DELETE requests. This seems to map more cleanly to what most adapters would typically need, and not-coincidentally resembles HTTP's approach. (I have more extensive thoughts on this, but wanted to post this now until I have time to write more.)

On Wed, Mar 30, 2016 at 1:49 PM, David Rajchenbach-Teller < notifications@github.com> wrote:

My impression, based on @mcav https://github.com/mcav's code, is that the following architecture works nicely:

• the adapter provides a Setter for creating (e.g. taking a new picture, adding a new rule, etc.);
• each entry in the CRUD is a Service, which can have one Getter for Read, one Setter for Update, one Setter for Delete;
• we use the Service's PropertyBag to store the creation date, the file name, etc;
• we use a tag to somehow specify to which device the Service belongs.

The main advantage of this is that this already works, without having to complicate the API or data structures, and that we already have primitives for watching the list of entries, accessing them, etc.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/fxbox/taxonomy/issues/53#issuecomment-203631200

[Yoric]

@mcav Interesting idea, I like it. Could you post your more extensive thoughts somewhere?

[Yoric]

So, based on @mcav's idea, we could add a slight redesign to the channels, as follows:

struct Channel {
  kind: ChannelKind,
  id: Id<ChannelId>,
  service: Id<ServiceId>,
  adapter: Id<AdapterId>,

  /// `true` if the channel can be used as part of a `fetch_values` operation.
  /// See `kind` for the type of values returned.
  fetch: bool,

  /// `true` if the channel can be used as part of a `send_values` operation.
  /// See `kind` for the type of values expected.
  send: bool,

  /// `true` if the channel can be used as part of a `delete_values` operation.
  delete: bool,
}

The main differences with what we have today are:

• new verb delete, with a corresponding operation delete_values;
• same Id for fetch, send and delete, instead of one for each.

Is this what you have in mind, @mcav?

[mcav]

Yes, I think bool flags convey all we need there.