On Fri, Jul 13, 2012 at 12:45 PM, Kalle Korhonen <[email protected]> wrote: > On Fri, Jul 13, 2012 at 11:36 AM, Howard Lewis Ship <[email protected]> wrote: >> Earlier versions of Tapestry tried to track versions of each library >> separately; you had to contribute a LibraryMapping to >> ComponentClassResourceResolver, and contribute a seperate value to >> ClasspathAssetAliasManager that included your version number. That >> was a lot of work and was error prone, which is why 5.2 switched to >> the one-version-number-to-rule-them-all. > > A lot of work for the library developer, right? For the user, it > should be the same. If we did it as I outlined and possibly even > contribute it on behalf of the library when it's loaded, what's the > harm? Almost every library has it's ImplementationVersion set in the > manifest. I'm barely thinking of Javascript here. Images and other > media formats, even if small will quickly add up to the overall weight > if they need to be needlessly re-downloaded every time.
Yes, work for the library developer, along with the issue of them releasing new assets and forgetting to rev the version number. Perhaps a service to track version numbers for libraries? It could take a contribution, as an override, or use some method to identify the version number automatically. > > I couldn't follow your thought on "this is for two reasons - security > - ability to enumerate..." What's this referring to? How's this > relevant to security? security classpath: assets can be all over the classpath. Although there are safeguards to limit what can be seen, people put odd things on the classpath, including .properties files that contain passwords, etc. Thiago, I believe, floated the suggestion (100% obvious in hindsight) that resources that might be exposed to the client should be segregated. By placing them under META-INF/assets, it is obvious what resources are meant to be on the server-side only, and which are allowed on the client. I believe we could manage this even with the modules, by writing RequireJS path configuration for each library that ensured that the library's version number was incorporated into the URL. So module "foo/bar" might expand to ".../modules/12345/foo/bar.js" and module "gnip/gnop" might expand to ".../modules/124c41/gnip/gnop.js" ... the version number goes between "modules/" and the library name, and would map to a META-INF/modules/ folder. enumeration For some CDNs, it is required (or at least, useful) to be able to identify all assets that may be extracted and pushed into the CDN. Currently, there's no way of doing that, for reasons that overlap the above. If all such assets were under META-INF/assets (or in the context), then generating the listing would be possible ... with the caveat that some asset urls (such as for modules, stacks) are virtual and there would need to be a system to support including such virtual assets in the inventory. > > What I love about Tapestry is that even if something's not implemented > I can usually get it done the way I want to by overriding a few > services without disturbing anybody else. However, this is one of > those things were I really dislike how it works and currently there's > no way to resolve it to my satisfaction. It's one thing to deploy once > a week, but imagine if we were deploying ten times a day - the costs > would add up very quickly and it's all unnecessary. > > > Kalle > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
