propose HIPE: message timing decorator #68
Conversation
Signed-off-by: Daniel Hardman <daniel.hardman@gmail.com>
Signed-off-by: Daniel Hardman <daniel.hardman@gmail.com>
Signed-off-by: Daniel Hardman <daniel.hardman@gmail.com>
text/message-timing/README.md
Outdated
| describing how long a system waited before retry might be named | ||
| `retry_milli`. Normally, this field would be represented as an unsigned | ||
| positive integer. | ||
| * `_el` tells how much time has elapsed in friendly, calendar based |
There was a problem hiding this comment.
Suggest being a little more specific on this one - "_elapsed" - "el" is a bit too subtle. I think we can afford the space. "t" and "tt" might also have other names - "_epoch" and something else for "tt" - not sure what that would be.
There was a problem hiding this comment.
Agreed on _el. Updated to _elapsed.
_t is a deliberate resonance with time_t in Posix. I added a note about it. _tt is just a double-precision _t. Although this isn't super self-explanatory, I think it's good enough.
text/message-timing/README.md
Outdated
|
|
||
| ### Decorators | ||
|
|
||
| Timing attributes of messages can be described with the `@timing` |
There was a problem hiding this comment.
I kind of think the fields are mixing concepts.
The first two are informational - tracking timing across an edge to edge message flow, presumably to learn about the network/processing time/delays. Since the only way to flow that information across participants would be in threads, the fields must be tightly tied to messages. These fields are not applicable to non-thread interactions - e.g. routing messages.
The other two fields are about altering message processing behaviour, possibly at the edge, but also useful within routing steps.
I suggest that the first two fields be added to the threading HIPE as optional fields, while the other two should be a separate HIPE about an implicit decorator that could be used by any message.
There was a problem hiding this comment.
I see where you're coming from, @swcurran , but I analyze this a bit differently. out_time is relevant no matter whether threads are active or not. And in_time and out_time could be relevant to a relay, even in routing (e.g., to measure how much time penalty is incurred by the relay). So I prefer to leave these in the HIPE. I agree that normal usage will devolve to just the set of fields that's relevant, but I don't think anything really belongs inside @thread, and I'd rather just leave everything together under @timing because I suspect we might think of other timing attributes in the future. For example, statistical measures (was the message I'm responding to an abnormally slow one), timing trends, scheduling (ideal delivery time or wait until time), etc.
There was a problem hiding this comment.
Perhaps part of the reason why I feel the way I do is that I don't analyze routing as a deeply separate concern from application-focused messages. Routing (in the form of the forward message) is just another protocol that some agents support. Today's simple imaginations of it will probably grow more complex over time, and the distinctions between routing and other stuff will seem less and less relevant.
Signed-off-by: Daniel Hardman <daniel.hardman@gmail.com>
dhh1128
changed the title
Signed-off-by: Daniel Hardman <daniel.hardman@gmail.com>
Signed-off-by: Daniel Hardman <daniel.hardman@gmail.com>
Signed-off-by: Daniel Hardman <daniel.hardman@gmail.com>
Signed-off-by: Daniel Hardman <daniel.hardman@gmail.com>
|
This PR is now superseded by Aries RFC 0032 (hyperledger/aries-rfcs#32) |
Signed-off-by: Daniel Hardman daniel.hardman@gmail.com