* Joachim Schrod <jschrod(a)acm.org> writes:
>>>>>> "BW" == Ben Wing <ben(a)666.com> writes:
BW> We really need to do things by HTTP.
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.
Interesting. So you are thinking of something that sets the transport
method based on something in `package-get-download-sites' and
`package-get-pre-release-download-sites'? I never thought of doing
that. Could be cool. Could also be too restrictive and a
maintenance PITA. Interesting, nonetheless.
> 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.
Here is something I was working on a year or so ago. It gives a local
transport, FTP (via EFS), HTTP, and scp. All that needs to be done is
to hook it into package-get.el. This package-transport.el will
obviously live in core.
> 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.)
Simple, you do it in such a way that there is zero impact on existing
package retrieval mechanisms.
> 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.
Probably not necessary unless you feel package-transport.el is flawed
(very possible, I haven't looked at since 2003). As I said above, all
that needs to be done is to hook package-transport into package-get.
If you want to do that, go for it! :-)
--
|---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---|
| In space, |
| No one can hear you rip a stinky |
|------------------------------------<steve(a)sxemacs.org>---|