Skip to content

Implementing an IImageScaleStorage that stores scales only in memory #32

@rafaelbco

Description

@rafaelbco

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:

>>> parameters = '{width:100,height:100,direction:'down',quality:88}'
>>> uid = base64(parameters)  
e3dpZHRoOjEwMCxoZWlnaHQ6MTAwLGRpcmVjdGlvbjonZG93bicscXVhbGl0eTo4OH0K
>>> len(uid)
68

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.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions