igbanam / butler

MIT License
0 stars 0 forks source link

Handlers #2

Open igbanam opened 4 years ago

igbanam commented 4 years ago

The problem of nested commands have pestered me for quite some time on this project. It may be due to my inexperience with the language, or blatant ignorance. In any case, I do not think my current solution works for handling nested commands efficiently.

Currently, there's a router which routes to instructions. While this seems viable: a request comes in, a controller should route this request to the right components with the right information to fulfil the request… two things are involved. Either

  1. there would be a knowledge hub which holds all information on routing requests, and
  2. this knowledge hub will grow to be some single point of failure

Rather than having a routing system, I think a more scalable way of doing this would be to have instructions at every corner, let every handler entity know how to route within its own domain. In a sense then, every command should have an embedded router until we get to the end state; the state where the request is fulfilled

igbanam commented 4 years ago

I still don't know if the "Handler" is the right name to use here. On one hand there's an instruction which comes from the user and is seen as a command from the system's point of view. Something needs to do this mapping. Sort of every command should have a handler type thing. This handler knows to "ingest" or "delegate" the current instruction it's looking at