architecture

architecture copied to clipboard

Context

Media player play_media service currently has an enqueue: boolean option. If set to true, the media player, if supported, will enqueue the media at the end of the current play queue.

Proposal

Expand the enqueue option to be an enum:

• PLAY: replace current queue
• NEXT: add to first place on the queue
• ALERT: pause current media, play media, resume previous queue
• ADD: add to end of queue

If enqueue is set to true, we will assume ADD.

The default is PLAY as that is what is the default today.

Consequences

It will be easier to control how media is played. Especially the ALERT option will be great for notifications.

I noticed this was updated in #72626 to:

• add: add given media item to end of the queue
• next: play the given media item next, keep queue
• play: play the given media item now, keep queue
• replace: play the given media item now, clear queue

(The above list is from the developer docs which were updated appropriately - just making the note here in case anyone comes across this discussion.)

Should the default still be PLAY or should it be REPLACE? When using PLAY, there may be unintuitive behavior such as sending a request to a long ago paused player with an existing queue. With PLAY, it looks like the "correct" behavior is to queue the new item and play it, and then have the player continue playing the older items in the queue. In this case I think REPLACE seems more intuitive.

This architecture issue is old, stale, and possibly obsolete. Things changed a lot over the years. Additionally, we have been moving to discussions for these architectural discussions.

For that reason, I'm going to close this issue.

../Frenck