@@ -288,7 +288,7 @@ \section{Security Considerations} % {{{
288288\begin {itemize }
289289 \item image upload spamming - should be avoidable by a meaningful limit
290290 on how many images can be uploaded at the same time.
291- Exceeding the limit will result in evicting older images in FIFO order ,
291+ Exceeding the limit will result in evicting ideally older images,
292292 leading to dangling image fragments, as their related image has been
293293 evicted. A placeholder or an empty screen cell will be displayed instead.
294294 \item huge image uploads - should be avoidable by limiting the number
@@ -570,13 +570,19 @@ \subsection{Storage Management} % {{{
570570Uploading a named image will associate the uploaded image with the specified
571571name and initialize the image's reference count to 1.
572572
573- When uploading an image would exceed the storage pool's guarantees,
574- the host may choose to actively evict images in FIFO-order until the new image fits.
573+ When uploading an image would exceed the storage pool limits,
574+ the host may choose to actively evict images.
575+
576+ The recommendation here is to use FIFO for eviction,
577+ but this is not a mandatory algorithm.
578+ If a terminal author comes with a much smarter eviction policy implementation,
579+ that should not in FIFO-order until the new image fits.
575580
576581If the image is larger than the allowed storage size, the upload will fail.
577582
578583Evicted images that were still held in screen cells will
579- either display a image placeholder or an empty screen cell.
584+ either display a image placeholder or an empty screen cell, neither
585+ is mandatory and free to chose by the terminal author.
580586
581587Displaying an image results in incrementing the reference counter
582588by the number of screen cells that are holding fragments of the image.
0 commit comments