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.

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?

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.)

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.