UI/API: Get message does not work for Stream queues

[jage]

Summary

When clicking "Get message" it just responds "No messages in queue", even though there are messages there.

Current Behavior

Pretty sure this is due to us using basic_get which isn't a thing for Stream Queues:

lavinmq/src/lavinmq/amqp/queue/stream_queue.cr

Lines 65 to 68 in fa0cbdc

	# Stream queues does not support basic_get, so always returns `false`
	def basic_get(no_ack, force = false, & : Envelope -> Nil) : Bool
	false
	end

Desired Behavior

I'd like to be able to "look at" any message in the stream, e.g. first, last or position N.

Screenshots/Mockups

[viktorerlingsson]

Yes, it's done because streams requires a consumer with some argument (x-stream-offset). But that can probably be worked around. I think it would be nice to be able to do this 👍

[kickster97]

We should build a nice way to have different queue views for different queue types like Streams or MQTT sessions, so we don't have to make lots of conditionals in the JS. Something generic so we can add more queue types in the future.

[snichme]

The form for get messages for a queue has Mode, Encoding and Messages (how many messages to get).
But in order to read messages from a stream there should also Offset for it to make sense.

It's even so that when you Get messages from a Queue you read from the end of the queue and backwards, since you pop the messages of the queue when getting them but for a Stream you set a starting point and you say how many messages you should get from the starting point and forwards.

But besides the semantic difference, we need a way to have different forms, and also some different handling in the queue.js which posts the request to backend.

Looking at #1284 it checks if the x-queue-type exists and if it's stream, we can do the same here and hide some DOM elements unless it's a stream but I see this as getting messy for future cases, like "Move messages" should probably have a starting offset and should not be "Move" it should be "Copy", "Purge Queue" should either not exists since a stream is persistent but if we want the possibilty (it can be nice to have) it should be called "Purge Stream" and in this IMO we should rename it from Queue to Stream.

Anyway, I'm landing in that maybe it's a good idea to have a separate view for a stream, but if so, how should we handle routing to /queue or /stream and how can we share html and js between these two?

[viktorerlingsson]

Anyway, I'm landing in that maybe it's a good idea to have a separate view for a stream

Agreed!

if so, how should we handle routing to /queue or /stream and how can we share html and js between these two?

Good question.. Maybe we can have something as a parent and load different partial views depending on what type of queue it is?

[kickster97]

I think its good to have separate view files for streams/queues (and moving forward also for sessions), there could maybe be some basics that can be broken out into common usage javascript modules.

 // containers.js
  export function setupBindings() { ... }

  // stream.js
  import { setupBindings } from './queue-common.js'
  setupBindings()

[kickster97]

hehe @viktorerlingsson beat me to it ^^