These places have to generalized. They should dispatch over a
transport protocol identifier that gets added to a download
site description. This way we keep backward compatibility
_and_ have the opportunity for other access methods (e.g.,
rsync, ssh) if needs arises.
This sounds fine to me.
The bigger problem is the actual HTTP access. Currently,
XEmacs provides HTTP access methods only in W3. Clearly, it's
a bad decision to make the package package dependent on such
a mass of code. That means that we need to implement a new
module. My thoughts are on an http.el along the lines of
smtp.el, built upon #'open-network-stream.
Of course, we also need to get Steve Youngs' agreement with
this approach; after all, package-get.el is him. As he just
answered on xemacs-beta; he doesn't want package-get.el to
depend on something not in core, and the http.el above would
not be in core. Or would it?
Yes, it definitely needs to go into core, otherwise you have impossible
But even if we put it in core,
there remains the question how we handle the upgrade path of
those installations where it isn't there yet. (I thought
about adding it to the package package; but that's not a
clean way, IMO.)
I think the simple answer is "we don't". The way to upgrade the core is to
upgrade XEmacs. We can certainly add this to the next 21.4, if we choose,
as well to 22.0 (due out soon?).
If we agree on a design, I would submit an implementation.
Next Sunday, I'll go for a one-week holiday and will have
some time for hacking there.
Go for it ...