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
> 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
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
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.
> 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
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