You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have an application where image scales are heavily used, and once they are generated they are stored forever, even when they are not useful anymore.
So I'm thinking about implementing a new IImageScaleStorage implementation, where scales are stored only in RAM memory. If memory was infinite it would be easy. However I would like to store the scales in a cache, where least used scales would get purged eventually (probably Zope's RAM cache, but that's just an implementation detail). The problem is when a client of the storage requests an image by it's UID and it is not in the cache anymore. Example: when a user requests the scale by its UID based URL.
To solve this the storage itself could re-generate the scale, but it doesn't know what are the scaling parameters (width, height etc). Unless the parameters are contained in the UID!
In the README I found this statement:
image scaling parameters should not be part of the generated URL. Since the number of parameters can change and new parameters may be added in the future this would create overly complex URLs and URL parsing.
However I thought of an easy way to solve the problems mentioned in the statement. I could encode the parameters as JSON and apply base64 encoding. For example:
URL would be not that big (67 chars in the example), parsing and encoding are straightforward and it is futureproof regarding inclusion of new parameters.
So what do you think? Do you see any caveats I am missing? Do you think such a scale storage would be generally useful and worth inclusion in this package? I could open a PR for that.
PS.: This is actually not an issue nor a question, it is a request for thoughts about this idea. I thought about posting it on the Plone Community forum but I think here I have more chances of reaching people how knows more about scaling specifics. I hope this is OK.
The text was updated successfully, but these errors were encountered:
For reference: I ended up implementing this via monkey patching, for Plone 4.3. Works quite well. We use memcached to implement the RAM cache shared by all Zope instances.
I have an application where image scales are heavily used, and once they are generated they are stored forever, even when they are not useful anymore.
So I'm thinking about implementing a new
IImageScaleStorage
implementation, where scales are stored only in RAM memory. If memory was infinite it would be easy. However I would like to store the scales in a cache, where least used scales would get purged eventually (probably Zope's RAM cache, but that's just an implementation detail). The problem is when a client of the storage requests an image by it's UID and it is not in the cache anymore. Example: when a user requests the scale by its UID based URL.To solve this the storage itself could re-generate the scale, but it doesn't know what are the scaling parameters (width, height etc). Unless the parameters are contained in the UID!
In the README I found this statement:
However I thought of an easy way to solve the problems mentioned in the statement. I could encode the parameters as JSON and apply base64 encoding. For example:
URL would be not that big (67 chars in the example), parsing and encoding are straightforward and it is futureproof regarding inclusion of new parameters.
So what do you think? Do you see any caveats I am missing? Do you think such a scale storage would be generally useful and worth inclusion in this package? I could open a PR for that.
PS.: This is actually not an issue nor a question, it is a request for thoughts about this idea. I thought about posting it on the Plone Community forum but I think here I have more chances of reaching people how knows more about scaling specifics. I hope this is OK.
The text was updated successfully, but these errors were encountered: