Hi.
In my company, we're in the process of specifying a Media Repository that will serve two purposes:
1. Work as a media/file repository for all of our web sites
2. Serve images transformed (with ImageMagick) according to pre-defined templates
A "template" is simply an XML snippet that describes how an image should be scaled, cropped, etc., to fit a given use on a web site. A typical example is "product thumbnail". I would like to build this system with AtomPub at its core and extend it where necessary. After having an initial planning meeting we have found some possible obstacles:
When POSTing a new image to the repository, it would be wasteful to transform the image to any available transformation template then and there, since we won't know if the image will be used in all available transformations. To preserve disk space, we would like the system to transform images only when a GET is performed on an URI representing a given image transformed through a given template.
When new templates are created, it should be applicable to all existing images without any heavy background services. Just doing a GET on an URI representing an existing image transformed with the new template, should be enough.
My colleagues are fine with the client "owning" the URI space and doing requests like:
http://example.com/acme/photos/image_123.jpg?template=123
Letting the client application build the URI makes it very flexible, but it is not a particularly RESTful design and makes the client instead of the server the owner of the URIs. I do, however, find it difficult coming up with an alternative design where the server still owns its URIs and where the client can "ask" to get any image transformed with any template regardless of when the image and/or template is created.
We also have a requirement in the system that it should be usable by many simultaneous clients controlled by many different companies that each should have access to their (and not anyone else's) media repositories. Is it problematic to have indefinitely nested collections and workspaces to solve this? This would allow customers to create virtual folders to store images in and such, which of course would be appreciated.
Any and all ideas are warmly welcomed. To summarize:
1. How do we give the server control of the URI while maintaining a flexible design that allows a client to request any image transformed through any template?
2. Is it problematic to nest workspaces and collections to allow several companies with different logins access to their own repository simultaneously?
3. Does something like this already exist?
--
Asbjørn Ulsberg -=|=-
asbjorn@xxxxxxxxxx
«He's a loathsome offensive brute, yet I can't look away»
