BW> We really need to do things by HTTP. This will solve all these problems. BW> What will this involve? There are ca. 5 places in package-get.el where remote files are accessed. These places are not specially functions, stuff like file-exists-p and insert-file-contents-literally, that rely on EFS to do the actual work. 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. Joachim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim The most exciting phrase to hear in science, the Rödermark, Germany one that heralds new discoveries, is not "Eureka!" <jschrod(a)acm.org&gt; (I found it!) but "That's funny..." [Isaac Asimov]