...
(2) "ABCD" repeated 1024^2 times
Protocol 0-8..0-10
Test Case | Protocol 0-9/0-10 | ||
---|---|---|---|
Content Type | On screen preview | Content Download | |
small text message | text/plain | complete string value | ditto preview |
large text message | text/plain | truncated string value | complete string value |
small map message (default) | amqp/map | Table containing name/value pairs Map entry with bytes array value is base64 encoded | The map's contents encoded as a AMQP 0-10 map
|
large map message (default) | amqp/map | Table containing name/value pairs Map entry with bytes array value is array of ints | |
small map message (legacy) | jms/map-message | Table containing name/value pairs Map entry with bytes array value is base64 encoded | Each written value is encoded by the TypedBytesContentWriter (2) |
large map message (legacy) | jms/map-message | Table containing name/value pairs Map entry with bytes array value is array of ints | |
small stream message | amqp/list | Table containing list values | The list's contents encoded as a AMQP 0-10 list |
large stream message | amqp/list | Table containing list values | |
small stream message (default - legacy) | jms/stream-message | No preview | Each written value is encoded by the TypedBytesContentWrite |
large stream message (default - legacy) | jms/stream-message | No preview | |
small object message | application/java-object-stream | No preview | Serialised object bytes |
large object message | application/java-object-stream | No preview | |
large pdf file | application/octet-stream | No preview | the pdf file. |
ff
...
Protocol 1.0
Test Case | Protocol 1.0 | ||
---|---|---|---|
Content Type | On screen preview | Content Download | |
small text message | Not present in AMQP 1.0 | No preview present on screen but getContent but returnJson true returns the bytes of the application payload itself. Note Content size reported is the size of the immutable sections, not the size of the application payload. | All the sections that comprise the immutable bare message, encoded in AMQP 1.0
|
large text message | |||
small map message | |||
large map message | |||
small stream message | |||
large stream message | |||
small object message | |||
large object message | |||
large pdf file |
(1)
...
(2) TypedBytesContentWriter is distinct from AMQP value system)
...
Current Problems
Preview feature
- As the preview feature uses JSON, which carries no type information, there is type-information loss (e.g. a ambiguity in the presented information. However, as the user of this feature is likely to have some familiarity with the application domain (perhaps as a programmer or operator), this is not necessarily a blocker. Examples:
- A list that comprises shorts
in - is indistinguishable from a list of ints
)- Some strings are indistinguishable from byte arrays encoded as Base64.
- The representation of byte-arrays is inconsistent between truncated previews of truncated and untruncated previews (Base64 for untruncated vs JSON array of integers for truncated ones),
- A byte array serialised as Base64 may be misinterpreted as a String. As we already offer a preview of the amqp/lists is seems odd that the same is not offered for the preview is offered for amqp/lists but not jms/stream-message, which is the JMS client's default for StreamMessage. There seems to be no good reason for this.
- There is no preview for AMQP 1.0 doesn't offer any previews (because the server currently only obeys returnJson if the message carries a known AMQP 0-8..0-10 mime type)message at all.
Content Download
- In AMQP 0-8..0-10, getContent is useful for the getContent operation usefully provides the bytes/text/object of messages. For users of AMQP 1.0, the getContent returns the concatenation of the immutable 'bare message' which is useless to the end user (unless they are prepared to decode the AMQP).
API
- The way limit applies to Json (truncating, but retaining a syntactically valid response if possible), seems surprising (at least to me)argument allows the user to get the first n bytes. There is no way for the caller to get the next n bytes in order to download chunk by chunk.
Suggested Changes
Preview feature
Server
...
- Standardise on returning byte arrays as array of integers
- For operation getContent if JSON is requested, it produces it only for Strings, Maps, Collections. For any other object payload, the operation must fail (say 422)
- For AMQP 0-8-0-10
- the above changes will mean that jms/stream-message messages will have a preview
- For AMQP 1.0
- for messages with payloads that are representable as JSON, the above changes will be sufficient give us the preview.
- for byte messages, with payloads that hold things like PDFs, there is currently no good place to adapt the content and extract the message payload. The underlying problem here is the store API. I suggest we don't fix this at the moment.
Side
- For structured payloads that include a byte array the JSON representation will always return an array of integers (rather than the Base64 encoded default of Json)
- Change the getContent operation so when
returnJson
is true, JSON is return regardless of the message's MIME type.
This will mean:
- This will enable the preview of for AMQP 1.0 message payloads and AMQP 0-8-0-10 jms/stream-messages
- This will mean that the caller won't be able to distinguish between an message containing a list of (small) integers from a message containing a binary octlet-stream.
WMC
- UI no longer considers mimeType
- UI changes to always render a preview of the first n payload bytes
- If the returned JSON object is a list containing only integers 0-255, UI guesses that the message is probably a binary octlet-steam. Display the preview as http://mephux.github.io/hexdump.js/
- If the returned JSON object is another type or a list containing larger integers, display preview as today.
Content Download
I don't see a reasonable way to enable the application payload for AMQP 1.0 messages. The underlying problem is the inability to get the application payload separately from the store. If we wanted a AbstractQueue hack we could do something like the below, but I am not suggesting we do this.
Code Block |
---|
private Content createMessageContent(final MessageReference<?> messageReference,
final boolean returnJson,
final long limit,
final boolean decompressBeforeLimiting)
...
if (serverMessage.getClass().endsWith("1_0"))
{
// Convert to internal message
return new MessageContent
{
// Stream the InternalMessage's content payload to the OutputStream
}
}
else
{
return new MessageContent(messageReference, limit, decompressBeforeLimiting);
}
|
API
I don't much like the getMessageContent's limit argument nor the ability to trim a structured message to provide a shortened by syntactically legal JSON response. As a user I think I would find the behaviour surprising.
I think I would have preferred that the REST API implemented RFC 7233 Ranges, and the REST API have the responsibility to chunk the response from getMessageContent. Chunks would not necessarily be syntactically valid JSON. If the client would need to intercept the "206 Partial Content" response and know that the response is incomplete. In this case, the client would fallback back on showing a hex dump style preview of the raw content bytes itself.
The getMessageContent API would have no knowledge of chunking.
https://tools.ietf.org/rfc/rfc7233.txt
...
- UI always requests content JSON content with limit. If the request fails with 422, add message "preview no available" to the UI.
- UI no longer considers mime type