Re: HTTP fetching
Steve Youngs wrote:
* Joachim Schrod <jschrod(a)acm.org> writes:
> 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.
Your package-transport.el looks great; I'll hook it up to package-get.el.
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? 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.
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.
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.
What do you think of this? Or am I wrong with my approach that the available
transport protocol are a download site property?
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Joachim Schrod Email: jschrod(a)acm.org
Roedermark, Germany