On some level, I'm doing something very similar to this post: how to serve dynamic content in playframework 2
Which is that I have a web app where clients can specify various parameters and we have the Play! server initiate a process that generates a custom image file...which then needs to be served back to that client, preferably by Play!
Anticipated image life expectancy could be anywhere from several seconds to several minutes (maybe even hours). From that angle, we have reasons to believe that attempting to send back the image data directly with the response is not a viable approach...and instead are going to send back a URL to that dynamic image.
I would also very strongly prefer to NOT rely on a separate HTTP server being set up to serve up these dynamic images for a variety of reasons. I believe the reasons are many, including but not limited to... maintaining a simpler architecture for both the developer work environments as well as the production servers. We have a very small/restricted user base with very few concurrent users (I don't believe serving up these images needs to be terribly high performance anyway - assuming Play! can serve up these dynamic images, I find it hard to imagine that the performance wouldn't be perfectly acceptable considering the simplicity tradeoff).
I've read that Play! assets in the public/ folder are compiled into an .jar file build/compile time which seems to explain why my tests of dynamic image generation and serving back don't work as expected - the results served back are always from the previous build.
Can anyone suggest a way of serving dynamic assets back without relying on another server?
