Re: package site information more dynamically updateable

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