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
#53 (comment)

[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.