search

swimos / cookbook

Cookbook code snippets, gathered into runnable Gradle projects.
Apache License 2.0
16 stars 8 forks source link

Dynamic Traits Cookbook #28

Closed AdityaRandive closed 2 years ago

AdityaRandive commented 2 years ago

This commit illusrates Dynamic Traits w.r.t. the Agents, respective properties and the shared lanes.

Author: Aditya R Reviewers: Ajay G, Rohit B Test: Manual Issue: https://github.com/swimos/cookbook/issues/24

AdityaRandive commented 2 years ago

The dynamic traits look good from a code perspective. Couple of suggestions

  • [x] It might good to have the logic of determining what trait to load based on the data passed into a lane, say config. You could call that with space.command and the payload can be a Value with a type key which may be "Water" or "Juice" . The callback function on the config lane could load the appropriate trait based on the value of the type. That way you can remove the props in the recon file for /liquid/:id
  • [x] Just the sharedInfo lane should be fine, not sure we need another `shared lane?
  • [x] Minor thing, maybe use proper agent names instead of random ints as ids. /liquid/distilled,/liquid/applesay. Also it might be best to have/liquid/sparklingand/liquid/orange` for the static traits to be consistent. What do you think?

Addressed (1) and (3). For (2) - cleaner lane sharing observed for static and dynamic, hence the two.

ajay-gov commented 2 years ago

@AdityaRandive The general pattern would be for the traits (i.e. Juice or Water to have logic that sets the shared lane which then gets reflected in the base agent i.e Liquid. So I think it will be good to move the calls to set the lanes to the Juice and Water agents.

Also having two lanes, one for sharing info of static traits and one for sharing info of dynamic traits, is a bit confusing. The main idea here is to show that you can have the same lane and use it across static and dynamic traits and share "info". That way downstream clients that access data from these agents can just subscribe to one lane i.e sharedInfo lane. Otherwise they will have to subscribe to two lanes which seems a bit more tedious.

AdityaRandive commented 2 years ago

@AdityaRandive The general pattern would be for the traits (i.e. Juice or Water to have logic that sets the shared lane which then gets reflected in the base agent i.e Liquid. So I think it will be good to move the calls to set the lanes to the Juice and Water agents.

Also having two lanes, one for sharing info of static traits and one for sharing info of dynamic traits, is a bit confusing. The main idea here is to show that you can have the same lane and use it across static and dynamic traits and share "info". That way downstream clients that access data from these agents can just subscribe to one lane i.e sharedInfo lane. Otherwise they will have to subscribe to two lanes which seems a bit more tedious.

ACK