Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!ispi!jbayer From: jbayer@ispi.UUCP (Jonathan Bayer) Newsgroups: comp.mail.elm Subject: Re: Local and remote signatures - a solution(?) Keywords: signatures Message-ID: <621@ispi.UUCP> Date: 4 Jun 89 15:48:50 GMT References: <398@sirius.ua.oz> <581@tiamat.fsc.com> Reply-To: jbayer@ispi.UUCP (Jonathan Bayer) Organization: Intelligent Software Products, Inc. Lines: 68 In article <581@tiamat.fsc.com> jim@tiamat.fsc.com (Jim O'Connor) writes: [deleted] >So far, IMHO, I like the idea of having the "signature" file selectable >from the headers menu. Or perhaps, the command to send, edit, etc the message >could include the option - c)hoose signature (I didn't pick a command clash, >did I?). If the message is s)ent whithout using c), the default behavior >would occur. If c) is selected, the user would have the option of >choosing between > >auto - signature appended according to the "usual" rules (whatever they > end up being) >local - append file specified by the .localsignature elmrc variable, regardless > of the rules >remote - append file specified by the .remotesignature elmrc variable, ditto >file - elm will prompt for arbitrary file name to append >editor - elm will put you back in the appropriate editor to enter the > text for the signature, and not append anything else >none - elm doesn't add anything to the message > >I include the "auto" selection in the menu, so that if a user changes the >"auto" behavior, they can put it back if they want to. > OK. I have been sitting back and watching, but now I think I will comment on this signature problem. Of all the suggestions that have come up, this is one of the better ones. However, it doesn't take into account the problem of a mailing list. If you have a mailing list of both local and remote addresses then either some of them will receive the wrong signature, or the user will be prompted for each address on the mailing list. If you make the stipulation that the selection is applied to EVERY address on the list, then this method should satisfy most people. For those diehards who like the older method of including the signature in the edited file, it might be conceivable to add a configuration question that asks for the old behaviour or the new. It could concievably might be able to make this an elmrc option. (personal opinions follow, flames to /dev/null, comments welcome) (hit 'n' to bypass) The problem of continuing development on a production program will be with elm forever. There will always be those who will be unwilling, or unable to adapt to and to use the new method. The development group can and should attempt to preserve the current interface, either through compile-time options or through run-time options. However, when it becomes necessary to change the functionality of the program in some way, and it is either impossible or unreasonably difficult to maintain the old method, then they should change it, BUT THEY SHOULD LET EVERYBODY KNOW THAT IT IS BEING CHANGED. This would give the users the opportunity to freeze their system at the current patchlevel, and ignore all future changes. Many people have said that they are holding at PL7, while waiting for this controversy to be resolved. That is the proper way to go. I have seen too many flames at the development group for this problem. The flames are unwarrented, since the users always have the option of returning to the PL7 version. Comments and CONSTRUCTIVE critisisms are always welcome. Remember: the elm development group is being done by volunteers. Nobody is being paid to do this. (end of commentary) JB -- Jonathan Bayer Beware: The light at the end of the Intelligent Software Products, Inc. tunnel may be an oncoming dragon 500 Oakwood Ave. ...uunet!ispi!root Roselle Park, NJ 07204 (201) 245-5922 jbayer@ispi.UUCP