HTTP fetching

Steve Youngs steve at sxemacs.org
Mon Feb 7 05:16:40 EST 2005


* Joachim Schrod <jschrod at 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 at sxemacs.org>---|
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 256 bytes
Desc: not available
Url : http://calypso.tux.org/pipermail/xemacs-beta/attachments/20050207/31e1ab41/attachment.bin 


More information about the XEmacs-Beta mailing list