I think when we start to say "we're going to add value" to a dependency, then we have to make it a hard dependency, and expect that everyone using the feature will be using the exact same version of the dependency.
If we go the "added value" route, then everything related to "adding value" should be in a separate package. I would suggest creating an actual "Ajax" package, so that the Ajax integration critters do not get mixed in with other unrelated extras. I think we should view this level of utility as an *extension* to the core framework. It should be something we can plug-in -- or plug-out -- depending on the needs of an individual project. If a project wants to use DWR or Dojo in a way that is incompatible with the way SAF2 "integrates" these packages, then the project should be able to opt-out of our integration scheme. Deciding to "add value" to another codebase is not trivial. I think it's a good idea, but it doesn't seem to me like "adding value" to an arbitrary dependency is integral to the core mission of the framework. I think an Ajax/Dojo or Ajax/DWR extension to the framework would be an good thing, but perhaps we should conceptualize the component as an opt-in/opt-out extension. -Ted. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
