On 9/27/06, Stephen McConnell <[EMAIL PROTECTED]> wrote:
> I make extensive use of custom protocols to represent links > to resources not contained within a particular project > code-base. These protocols include the following: > > 'artifact' used to resolve resources from a collection > of remote hosts (where the definition is 'remote' > is a configurable characteristic) based on group, > name, type and version data > > 'local' used to reference local preference information > using the same 'group', 'name', 'type' and > 'version' pattern > > 'link' a symbolic reference that enables one group, > name, type, version reference to point to another > resource
The concept of REST (http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm) is coming to mind as I read this. What you have in the next paragraph is very REST-ful in its way of encoding location, version and name in URLs. I would ask us to consider (Occam's Razor in hand) at what point one actully needs to create a custom protocol (and code to support it) versus using REST-ful URL conventions to achieve much of the same thing with existing protocols and software.
> All of these protocols include support for the establishment > of a locally cached file that is a copy of the remote > resource (partly driven by the need to handle the > relationship between models of projects and Ant's build-time > requirements). Typically a link such as > link:jar:acme/widget#1.2 (a symbolic link defining a jar file > under the group namespace acme, name widget, with a published > version of 1.2) could reference an artifact such as > 'artifact:jar:net/osm/demo#1.2.9', which in turn maps to a > range of possible sources where each source defines its own > scheme for artifact to path transformation (i.e. the > automation of the transformation of the artifact > specification to something like > file://d:/dpml/data/cache/net/osm/jars/demo-1.2.9.jar is an > example of one of potentially multiple source paths).
Another take on the following statement is that location is a concern to make explicit to the reader of a build script, rather than obscuring a thing's actual location inside of a protocol handler black's box.
> The key thing is that these protocols enable the removal of > location concerns by shifting the focus to identity.
Just some thoughts on this interesting topic. I don't buy the need for all these protocols and handlers or the associated flexibility in Ant (yet). Scott Stirling Framingham, MA --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
