#1089 closed todo (done)
Command instance management
| Reported by: | Ichthyostega | Owned by: | Ichthyostega |
|---|---|---|---|
| Priority: | normal | Milestone: | 0integration |
| Component: | lumieraSteam | Keywords: | interfaces integration command session lifecycle |
| Sub Tickets: | #209, #215, #300 | Parent Tickets: | #144, #269, #399, #1058, #1060, #1087, #1090, #1094 |
Description (last modified by )
Session commands are prototype objects.
For that reason, it is mandatory to create a distinct instance for each case where arguments are to be bound.
Effectively this means that we'll be constantly creating new (clone) instances, wait for them to be bound with arguments, and then "burn" them by passing them to the SteamDispatcher
So the task here is to build a new facility in Steam-Layer, the CmdInstanceManager, which
- on demand will "open" the next (clone) instance for a given command definition
- provides a suitable Command-ID
- allows to consume the currently open instance, by handing it over to the
SteamDispatcher - after which there is no current instance and the next request will restart the cycle
Change history (9)
comment:1 by , at 2017-03-18T16:42:19Z
| blocking: | 144, 1087, 399, 1060, 269 → 144, 269, 399, 1060, 1087, 1094 |
|---|
comment:2 by , at 2017-03-31T16:42:41Z
| blockedby: | 215, 300, 208 → 208, 215, 300 |
|---|---|
| Owner: | set to |
| Status: | new → accepted |
comment:3 by , at 2017-04-01T01:00:26Z
- turns out we do not need a running counter
- coded up basic implementation, relying on anonymous command instances now
- written basic unit test, which does not pass yet (the command instance doesn't arrive in the Fixture queue)
comment:4 by , at 2017-04-08T22:48:48Z
| blocking: | 144, 269, 399, 1060, 1087, 1094 → 144, 269, 399, 1058, 1060, 1087, 1094 |
|---|
comment:5 by , at 2017-04-09T17:16:05Z
A CommandInstanceManager is now implemented, covered by unit test and integrated into the SessionCommandService. I have chosen to keep this feature optional, which means, it is still possible just to bind and invoke globally registered Commands without much ado. Just, the SessionCommand-facade has now an additional operation, allowing to "open" a new command cycle, and the instanceID returned by this operation can later be used to address such a local (anonymous) command instance similar to a globally registered (named) command instance. In fact, doing so is expected to become the standard use case.
What remains to be done for this task is to see how this fits in with the (planned) CmdAccess front-end #1090
comment:6 by , at 2017-05-02T19:33:25Z
| blocking: | 144, 269, 399, 1058, 1060, 1087, 1094 → 144, 269, 399, 1058, 1060, 1087, 1094, 1090 |
|---|
looks like this is basically settled.
comment:7 by , at 2018-03-10T21:19:26Z
| blockedby: | 208, 215, 300 → 209, 215, 300 |
|---|---|
| blocking: | 144, 269, 399, 1058, 1060, 1087, 1094, 1090 → 144, 269, 399, 1058, 1060, 1087, 1090, 1094 |
| Resolution: | → done |
| Status: | accepted → closed |
almost a year has passed by...
And while the whole topic of command handling feels rather unfinished, it does not look like we're able to treat it statisfactory anywere soon. But regarding the aspect how to manage the command instances, no new concernes have emerged since quite some time, so I tend to consider this part more or less settled by now.
comment:8 by , at 2022-10-21T22:05:33Z
| Description: | modified (diff) |
|---|
comment:9 by , at 2025-12-25T00:00:00Z
| blockedby: | 209, 215, 300 |
|---|---|
| blocking: | 144, 269, 399, 1058, 1060, 1087, 1090, 1094 |
| Parent Tickets: | → 144, 269, 399, 1058, 1060, 1087, 1090, 1094 |
| Sub Tickets: | → 209, 215, 300 |
Migration MasterTickets ⟼ Subtickets-plugin
