On Fri, Oct 5, 2012 at 6:28 PM, Howard Lewis Ship <hls...@gmail.com> wrote:
> Sounds nice; that's how I've always assumed CDNs worked (lazily) > though I'm told other require an explicit load of assets into the CDN, > which is tricky in the Tapestry world where many of those assets are > dynamically generated (or compiled, or aggregated). > Yes, it works great with dynamic content - although we have to disable cdn during releases as we currently don't do an atomic update in cluster. If we didn't then users will be missing assets as we use a cookieless domain for that. (Expect to do atomic updates soon though.) Regarding AssetPathConverter - should I open a JIRA for stack assets? On Fri, Oct 5, 2012 at 10:37 PM, trsvax <trs...@gmail.com> wrote: > I wrote a CloudFront CDN while ago and also ran into a few problems. Is > loading content other than from S3 a new feature? It's not new - think they started beta back in 2008. However they launch new features all of the time. > I wrote a CDNManger > service that Lazily loaded the assets onto S3. The problem I ran into is > Tapestry uses the same URL to deliver compressed and uncompressed content > depending on the client request. I suspect if you just point ClouldFront > back to your Tapestry app you will have strange problems with old browsers > No, compressed files is supported with cloudfront so it should be a non issue. It respects the Accept-Encoding header. http://docs.amazonwebservices.com/AmazonCloudFront/latest/DeveloperGuide/ServingCompressedFiles.html As a cdn, cloudfront is superior to s3. They serve different purposes, but work well together. s3 can easily be configured as origin to cloudfront and you pay no additional cost for this. I'm a satisfied user of both.
