With the snapshots repo down, there was some discussion on IRC.
Joakim mentioned there was some discussion of a resolution that was
"DNS-like, not actual DNS" and it got me thinking DNS might be a
better solution (possibly with RFC-2782 extensions) to resolve
repositories. Apologies if this echos discussion at ApacheCon.
This solves some problems:
1) Downtime at well-known repositories such as we are seeing today
could be backed by the actual repository that released the code. If
a central repository goes down, the source repository that provided
the original artifact would act as a fallback. DNS is distributed,
so there is no central point of failure for artifact resolution.
2) Authenticity of artifacts is validated by control of DNS. The
current method of getting an artifact into the central repository
isn't scalable. If you know someone well enough, they put your code
into the repository. If you don't know someone, your request gets
put on a list of things to do. It's the way it has to work with a
central repo. But if the repo could be found by DNS resolution,
anyone could publish. It's up to the client to decide if a jar with
<groupId>org.viruswriters</groupId> is safe to depend on, and it can
be resolved without burdening central repository maintainers to
decide whether to publish it since the crew at viruswriters.org could
simply add their external repository to DNS. Done.
3) Use of artifacts could be logged. I would like to be able to use
log analyzers to know who is using my artifacts and what part of the
world they are coming from. I can't do this with a central
repository. If I have a sufficiently fast line, I should be able to
run my own repo and collect these logs.
Central repositories are still important, but their role would change
to a fast cache of the distributed repos. Artifact suppliers would
be mirrored if their artifacts were considered important enough and
mirroring them would speed up builds for the masses, not because
someone successfully campaigned to get their artifact in.
WDYT?
-b
