Re: HTTP fetching
* 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>---|
Attachments:
- attachment.sig (application/pgp-signature — 256 bytes)
- attachment.bin (application/emacs-lisp — 16.3 KB)