| A few issues I have with UMF. It's missing a mission statement, or use case. The intro says it's used to avoid inconsistent formatting, but there exists other message formats. The body field is application specific, which introduces an area for inconsistent formatting and reduces the interoperability, or universalness, of the message format. The destination doesn't need to be in the message, most of the time the destination is implicit in where the message is sent. (If I send a UMF over email the destination would be in the email metadata and the UMF metadata) The total amount of metadata that would be included in a UMF message sent over TCP/IP would be silly. There are arbitrary and undefended specification decisions. The transport protocol is left ambiguous, but both the schema and the format are specified. The metadata around body is very standardized, but anything goes inside body, which is the primary payload. |
The point about inconsistent formatting is that by aligning a team(s) on how a message is formatted groups can avoid the introduction of multiple message formats between distributed services.
It's true the body field does introduce inconsistency and that's left for the application developers to resolve. The envelope fields are intended to be used in queuing and routing situations.
I disagree with "The destination doesn't need to be in the message". What about the use case where a message is forwarded or moves through proxy services?
+1 for metadata being larger than the payload :-D - Can't debate that. The only required fields are 'to', 'from' and 'body' and the short form of UMF can be used. Still, we've encountered situations where that metadata is still larger than the payload. But that doesn't completely invalidate the presence of the envelope in a distributed application.
Thanks, I really appreciate the time you took to offer feedback!