Alex Karasulu wrote:
Ok I'm a little dense so bear with me. I see the webserver now recognizes and sets the mime type based on the .meta file extension. Why is this so significant to us?
It means that the client application (i.e. the repository implementation classes) can take advantate of the x-meta mime type. Based on the user supply of a group and artifact we can make a request for the meta data without resorting to a url that exposes anything more than the fgroup and artifact.
Specifically:
http://www.apache.org/~mcconnell/test/example
This url is sufficient for the retrival of the jar (a mime type) and the meta about the jar (another mime type). Instead of building an explict url to a <something>.meta - we can use HTTP content rules to get what we want (jar versus meta data about the jar). This means that the question of how meta data is associated with an artifact is no longer a client concern - its a server implementation concern.
Your example is also very confusing to me as well. Can you explain it? Why would trying to get http://www.apache.org/~mcconnell/test/example work. You only have the following in this directory:
example.jar example.jar.meta
Yep.
The artifact url is http://www.apache.org/~mcconnell/test/example
Relative to that artifact there are a number of resources that are potentially resolvable - example.jar and example.jar.meta. According o the HTTP protocol spec we can set an "Accept" request property to guide the server in terms of content negotiation. I.e. the group/artifact is sufficent with respect to url - the rest can be resolved using content negotiation support.
http://httpd.apache.org/docs-2.0/content-negotiation.html
Steve.
(who is figuring this stuff out as he goes along).
--
Stephen J. McConnell mailto:[EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
