-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Apr 22, 2005, at 12:19, Mykel Alvis wrote:
If the manner of accessing the repository were abstracted, one might be able
to write a repository manager that would retrieve dependencies arbitrarily
from a service rather than from the filesystem. For instance, someone could
write a manager that, when supplied with a particular dependency, went and
retrieved that dependency from a blob in a database, and was therefore
referenced by an id rather than a filename.
Not that the two things are different, mind you. You still have to provide
some indicator for versioning as part of the id. However, based on the
property service that I think we're going to work on internally here at my
company, I can see a dependency service that works in a similar fashion.
I don't think there's anything standing in the way of that now. Such a repository manager would simply have to speak HTTP.
For instance, you define your local repository as being at the URL http://www.example.com/cgi-bin/repository. The "repository" script/executable receives the rest of the URL (for instance, "/commons-collections/jars/commons-collections-3.1.jar") as extra path info, and can parse it or split it up or whatever and use that information to retrieve or generate the dependency as needed.
I would think the biggest concern with generating dependencies on the fly would be keeping the HTTP connection from timing out.
Interesting idea, though.
- -- Craig S. Cottingham [EMAIL PROTECTED] OpenPGP key available from: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x7977F79C -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin)
iD8DBQFCaThTEJLQ3Hl395wRAsX6AJsF77NG6S9BX5mbWCZTmQhLnaHMgwCgrANz hebGSf/XE7xR/YIBnR2n32I= =6Px8 -----END PGP SIGNATURE-----
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
