On Sun, 2005-10-23 at 20:01 +0200, Adrian Aichner wrote: Yes, sure, that's why I threw in the idea of moving these lists to xemacs-base... AFAICS, no new problems would be introduced by doing that compared to the current situation.

* Adrian Aichner <adrian(a)xemacs.org&gt; writes: I object. These lists don't change anywhere near often enough to warrant them not being in core. Moving them out of core and into packages is a step away from the goal of a working PUI in a "packageless" XEmacs. IMO, PUI should work from `xemacs -no-autoloads'. -- |---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---| | I am Dyslexic of Borg. | | Fusistance is retile. Your arse will be laminated. | |------------------------------------&lt;steve(a)sxemacs.org&gt;---|

* Adrian Aichner <adrian(a)xemacs.org&gt; writes: No. And I didn't suggest that it did, I just said it _should_. No. But you _should_ be able to. Moving the list of download sites out of core is a step in the _wrong_ direction. -- |---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---| | I am Dyslexic of Borg. | | Fusistance is retile. Your arse will be laminated. | |------------------------------------&lt;steve(a)sxemacs.org&gt;---|

Steve Youngs wrote: i agree.

* Adrian Aichner <adrian(a)xemacs.org&gt; writes: You don't need Dired. I don't see how the method of transport would have any bearing on where the list of sites can/should be kept. -- |---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---| | I am Dyslexic of Borg. | | Fusistance is retile. Your arse will be laminated. | |------------------------------------&lt;steve(a)sxemacs.org&gt;---|

* Adrian Aichner <adrian(a)xemacs.org&gt; writes: Removing PUI's dependence on EFS doesn't have anything to do with where the list of download sites is kept. -- |---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---| | I am Dyslexic of Borg. | | Fusistance is retile. Your arse will be laminated. | |------------------------------------&lt;steve(a)sxemacs.org&gt;---|

Ben> yes, we should put xemacs-base into core. I disagree. That will just bite us later with shadows and backward-and-forward incompatibility. We'd be much better off defining reasonable interfaces where we can and moving that stuff _out_ of core, while providing a facility for installing minimal packages or SUMOs from the distribution tarball. Things like URL fetching etc are perfect candidates, since they're basically defined by RFCs. On the other hand, our specific UI features are candidates for moving back into core (I'm thinking specifically of annotations and fields), if we can't standardize the APIs well enough to make them "public stable". I know having stuff in packages is annoying to you, Ben, but I believe that the prospect of working with that big ball of mud we call "core" is a prohibitive deterrent to a lot of people who might otherwise contribute an occasional fix. Ben> yes, we should switch to an http package installation Ben> system. (really really really; http is *much* more reliable Ben> than ftp these days and works through firewalls consistently) This would be a lot easier on the users if package-get were itself in a package. -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.

Stephen J. Turnbull wrote: moving core stuff out of core just introduces more and more dependencies between core and packages. if we maintain the stuff anyway, and its critical to the core, there's zero point in it being in the packages. what's your evidence? has it stopped contributors to gnu emacs, where there is even more in the core? why? it has to get implemented, either way. core or package won't make much difference except that putting it in a package means someone has to go to extra work to implement the "put the packages in the core distribution" bit. will that be you? ben

Ben Wing wrote: Just as a side note: I have code that adds http and ssh transport support to package installation. It's based on package*.el from 21.14-CVS and on functionality from package-transport.el by Steve that got posted here many months ago. The code is upwards compatible to existing descriptions, to ensure that customized package-get-download-sites continues to work. It adds an optional fourth attribute to the download site description, the protocol that can be used to access the given site and directory. (Actually, one should and could use URLs as site specifiers, IMO. But that can be a later addition.) Btw, the code does _not_ use the concept of Steve's package-transport.el that had a global variable that denotes the transport protocol. IMNSHO the transport protocol is associated with the site and is not a user preference. One could have a user preference that filters out all download sites which don't support the respective transport protocol, but that hasn't been implemented yet. I haven't posted the code yet to xemacs-patches because it doesn't support http proxies yet, doesn't support http ports other than 80, there is a problem with overwrite semantics of copy-file, and I have to make more tests. Cleanup (comments) is needed, too. If somebody wants to see that 80%-ready code nevertheless, I can make it available, of course. Cheers, Joachim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod Email: jschrod(a)acm.org Roedermark, Germany

Joachim> If somebody wants to see that 80%-ready code nevertheless, I Joachim> can make it available, of course. SJT> Please do. Thanks! I did so, to xemacs-patches. Independently from the code patches, some general stuff about requirements and design decisions that cannot be associated easily to one code place, but should be known nevertheless. Design of Package Download Over Various Transport Protocols =========================================================== Requirements: ------------- -- Currently only package depots may reside only on local file systems and on ftp servers. HTTP and ssh access shall be supported as well. -- Not all mirror sites provide both ftp and http access. -- Directory names may differ between http and ftp access for the same site. -- The code shall be company-friendly: HTTP proxies (potentially with authentication) must be supported. -- Customized (i.e., potentially personalized) variables shall keep their semantics. Additional semantics are possible. Design Decisions: ----------------- The transport protocol gets part of a download site description. HTTP and ftp access to the same host are two download sites. Since package-get-remote is potentially customized, we need to keep the basic site description structure. Currently, it's '(DESC HOST RDIR) where RDIR is a (potentially relative) directory name. In the future, it's '(DESC HOST DIR PROTOCOL). -- DESC is a string with the site description -- HOST is a hostname or NIL. For http and ssh, it may be HOSTNAME:PORT. If it's NIL, it's the local host. -- DIR is an absolute path. For backward compatibility, relative directory names are supported for ftp and local files. -- PROTOCOL is either 'file, 'ftp, 'http, or 'ssh. For backward compatibility, it is optional; then PROTOCOL defaults to 'file if HOST is NIL and to 'ftp otherwise. Alternatively, it would have been possible to use '(DESC URI) as new site description. URI is then something like PROTOCOL://HOST:PORT/DIR. The advantage of such a description would be the familiarity of URLs for many people and that a user can enter such a URI at a prompt, but current site descriptions may not be entered easily. => This needs discussion with the XEmacs folks. Now the user interface for site selection suddenly gets unwieldy. The selection list gets too long, since we get almost twice as many entries as we have now. How do we make that interface usable again? This is a completely open question; I cannot yet answer it. An idea: we could introduce regional attributes, for continent and/or country. Then we could add submenus, similar to the nested list that's on http://www.xemacs.org/Download/ now. (But I'm not proficient enough with customize to realize that with small effort.) Smaller Design Questions: ------------------------- Currently, the code tests readability of the index file and issues a separate error message for `exists but is not readable'. That test is not done for package files, there the copy causes an error message if it's not readable. That test for readability must be implemented for all transport protocols -- ain't it sufficient to just wait for the copy error and report that properly? (Existence is always properly tested, that's not the question.) The package depots are all supposed to be publicly accessible. I.e., no authentication for depot access is supported. Do we want to add such possibilities? If yes, for which protocols: ftp, http, ssh; and how is the password managed and stored? Cheers, Joachim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod Email: jschrod(a)acm.org Roedermark, Germany