| My dude should quit his architect positions. Consistent hashing of messages requires that every application which handles the message will lay the fields out in the same manner, this is a recursive problem for every layer that will put its data in the UMF. This right out the gate creates caching complexity issues. Also for being so no cache control options by default. Also there isn’t an error handling/logging field so the responder will have to do something out-of-band to acknowledge errors. Also there’s no mention of compression or alternative message formats, XML, proto, etc. The sender field should likely be a URI encoded data. Then which mode (of several) which could get the message is an infrastructure not an encoding program. Getting this deep here is kind of bad, same with the TTL. If we are going this deep... why no cache control/consistent hashing/compressing? If you care about strictness or correctness you should use RFC3339 instead of ISO8601. Also not including an implicit UnixTime/UnixTime Nano seconds is a poor choice. Offering alternative keys for standard keys is dumb. This feels like an accident that nobody caught until later, and made a backwards compatible monkey patch. Why haven’t you considered protobuf if you have concerns about message size, and are working in power constraints? UTF/Base64 is kind of shitte for power savings. |
The conical issue with regards fields and signatures is definitely and without question a valid point and should probably be removed from the spec.
You raise good points. I'll definitely reconsider your feedback in future iterations!
Your point about a logging field is interesting, but the MID field could be used in an out of band error acknowledgment.
Protobuf is great - but what if you don't need or want it?
Thanks for taking the time to comment!