THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
| 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 | Error popup 'unknown code 67' No preview displayed. Broker survives. Stack trace (1) | 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. |
...
- The way limit applies to Json (truncating, but retaining a syntactically valid response if possible), seems surprising (at least to me).
Suggested
...
Changes
- Server side
- 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.
- UI
- 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
...