> You're saying that those interested in enabling a repo with
> metadata and searches based on this metadata could wrap the
> repository with a servlet.
Could? Yes. But that is just one way of many. I maintain that httpd could
serve the content of most repositories, meta-data and all, without dynamic
content generation.
> The URI could be used by the servlet to give a different view
> of the repository based on [criteria embedded in the request]
IMO, the request should to encode the complete request. There should not be
any other implied context.
> the servlet manages the interaction behind the scenes with
> some sort of metadata database to conduct the query and
> return the results as if they were regular files on the
> server's repo file system.
It depends upon the repository implementation. It could work as you
describe, or there could just be pre-built metadata stored in files.
Consider that eventually web sites will likely use Subversion with WebDAV as
their authoring mechanism. Authorized people will post directly to a
Subversion repository. Although httpd can load directly from Subversion,
that will not be as efficient as serving directly from the file system. The
reason for that is that sendfile() does not work directly out of a BDB
database (as far as I know). Therefore, when a file is posted to
Subversion, it could be mirrored by a hook to a directory representing the
current content, which is what would then be served by httpd. We used a
similar technique at GEIS years ago with SourceSafe, so that when a checking
occurred, a copy went into a shadow directory, and a build test was
initiated. Likewise, a tool could be invoke to build meta-data, and store
it in the file system.
So there are ways and ways and more ways. The goal is the same, as should
be the externally viewable behavior.
--- Noel
