Eli Zaretskii writes: >> From: Manuel Giraud >> Cc: stefankangas@gmail.com, 68006@debbugs.gnu.org >> Date: Mon, 21 Oct 2024 12:12:12 +0200 >> >> Eli Zaretskii writes: >> >> [...] >> >> >> For the moment, I wanted to keep it minimal so the only interface to use >> >> it goes as follow. When a user (or a program) use the image attribute >> >> ":ttl TIME_IN_SECONDS" with `create-image' such image will be stored in >> >> the « user cache » and not in the internal one. Images lookups use both >> >> caches (internal and internal, in that order). A negative >> >> TIME_IN_SECONDS means « cache this image forever ». >> > >> > Why do we need a separate cache for this? couldn't we instead just add >> > the EOL field to the single cache we already have? having two caches >> > requires to search both of them, which slows down image look up, so if >> > we can avoid that, it's better. >> >> That's you (in this thread) that suggested having another cache for more >> "user controlled" usage and suggested that lookup_image could search in >> both caches. > > I said that assuming the difference will be more prominent than just > one field. > > The implementation could be a single cache with a field or fields that > distinguish between the two kinds of cached images. Yes, that makes sense. >> >> I think there will be a need for user function that completely flushes >> >> the images in this new cache. But do you think we need others commands >> >> for such interface? >> > >> > We probably need a way for modifying the time an image is to be kept, >> > at least. >> >> Yes. Anyway, my last patch was completely wrong and I am working on >> another one. Tell me if you're interested to see where I'm headed to. > > It's your call. I and others are here to provide feedback if you feel > you need that. Anyway, here is a patch of what I have done. Since in the end an image is identify by an ID which is its index in the images vector, I choose to take this vector out of the cache struct and put it into what I called an image_store. Now there are two caches (internal (as before) and user's) that both use the image_store. In order to make this work, I needed to add a reference to the cache that manage it in each image. But, as you said, for just one other field, this code might be over-engineered and also quite error-prone.