>I'm sorry, but I don't agree. LISTSERV *already* will not run on a >majority of BITNET sites, so that argument doesn't mean much. There are over 200 LISTSERVs on the network, about 5 of which run on a system which has SFS. None of the systems on which I presently have an account is SFS capable, for example. And I have a lot of accounts on a lot of systems. >Yes, you would still need an authorization list for files, but you would >NOT need a FILELIST per se. Sorry but you are not making sense. In your previous posting you said that the interface to the user should remain constant. For non-SFS systems I do need a filelist, therefore the filelist must also exist for SFS systems. And by the way, the filelist is *not* the place where the information "file A B from filelist C is fileid X Y Z" is stored. >Also, I am not sure what security considerations you are referring to, >re: aliasing fileids. I am, and I am not very keen on the idea of describing them in any further detail. >but if it is possible to move away from that kind of application-level >simulation I think the possibility should receive a much more serious >treatment than what it's received here. Could you please elaborate on this? >And even if SFS proves NOT to be a reasonable alternative, I think the >FILELIST support needs to be tightened up. A maintainer should not have >to hand-edit FILELISTs to add, remove, or rename files. Absolutely. This is all planned for version 2 of LISTSERV. But this is another issue entirely. Eric