Re: HTTP fetching
* Joachim Schrod <jschrod(a)acm.org> writes:
Steve Youngs wrote:
> 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.
Your package-transport.el looks great; I'll hook it up to
package-get.el.
Cool.
Concerning my proposal above: It started with a design question. Is
the transport protocol a property of a download site, or an overall
property? I.e., can we assume that _all_ XEmacs mirrors provide at
least the protocols HTTP and FTP?
No. The only thing you could assume is that they serve those
directories up via FTP. Some of them _might_ serve via HTTP as well,
but that is definitely _NOT_ the case for all of them.
Someone from the Review Board (preferably Norbert as he is the XPRM)
should get in contact with _all_ of the mirrors and ask them if they'd
be willing to serve up the package directories via HTTP as well as
FTP.
Unfortunately you can't just jump in a browser and see which ones will
respond. Not all of the sites are accessible world
wide. (mirror.aarnet.edu.au is a classic example, it can only be
accessed from within Australia)
If not, explaining the package mechanism is a nightmare. One cannot
say, choose a mirror and then choose a transport method. Which one?
Would you need to look it up on the XEmacs Web Site? IMO too complex
for a new XEmacs user, and PUI should work for a newbie without much
headache.
Exactly one of the reasons that package-transport.el has laid dormant
on my hard disk since 2003. :-)
When we add a fourth element to a download site description list,
this 4th element could be your package-transport-method. When an
XEmacs mirror is set up, the mirror maintainer tells his access
methods to the XEmacs guys, and they can record these access
methods in the site description. Not much pain in maintenance;
but easier for the end user.
That does sound pretty good.
This 4th element would be optional and default to ftp, if the site
name exists and to local if it's nil. Thus, existing personal
package-get-remote customizations still work.
Good.
What do you think of this? Or am I wrong with my approach that the
available transport protocol are a download site property?
I think this is a good idea. The idea certainly gets my approval.
--
|---<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)