mrp@sirius.ua.oz (Mark Prior) (05/30/89)
I think most of the problems with signatures would be solved if it was possible to configure what addresses the user considered were local. Suppose there existed a file (eg. .elm/local_addresses) that contained address templates that indicated to elm which addresses were to be assumed as local, these templates could be either addresses with wildcards or aliases from the user's (or system's) alias files. For example I would consider all mail to people at the Uni to be local and maybe some mail to other people outside as local (ie I want to use a local signature) so I would have a file like - *@*ua.oz.au person-alias group-alias Elm would then pattern match on these templates to determine whether the addresses were `local' or not and then append the appropriate signature file to my mail message. Mark. -- Mark Prior Phone : +61 8 228 5680 University Computing Services Telex : UNIVAD AA89141 University of Adelaide Fax : +61 8 224 0464 GPO Box 498 Adelaide S.AUSTRALIA 5001 ACSnet: mrp@sirius.ua.oz
jim@tiamat.fsc.com (Jim O'Connor) (06/04/89)
In article <398@sirius.ua.oz>, mrp@sirius.ua.oz (Mark Prior) writes: > For example I would > consider all mail to people at the Uni to be local and maybe some mail to > other people outside as local (ie I want to use a local signature) so I > would have a file like - > > *@*ua.oz.au > person-alias > group-alias > > Elm would then pattern match on these templates to determine whether the > addresses were `local' or not and then append the appropriate signature > file to my mail message. This would be a workable solution for "configuration file literate" users, but most of my users still don't understand that .elm/elmrc and .newsrc exist and/or what they are used for, much less a .elm/local-users file. 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. This method would maintain the fixes from patch8 in this manner: 1) when the user doesn't care, the "auto" mode will take care of appending the "appropriate" signature at the time the s)end command is issued, thus the to and cc headers can be examined. 2) when actually appending a file, the file will still be appended at the time s)end is issued, so that users using the built-in editor can use signatures. There is also some added functionality, in that the user now has the option to keep several different signature files, and append the one they want on a message by message basis. The folder concept could even be extended, so that there would be a "Sig" directory with signature files, and "=file" would specify a file in this directory, when using the "file" option listed above. Getting back to my original "configuration file literate" users concern, I think this method would be easier for novice Elm users to understand and make good use of, while still allowing advanced Elm users to have the flexibilty and functionality they desire. --jim ------------- James B. O'Connor jim@tiamat.fsc.com Filtration Sciences Corporation 615/821-4022 x. 651 *** Altos users unite! mail to "info-altos-request@tiamat.fsc.com" ***
jbayer@ispi.UUCP (Jonathan Bayer) (06/04/89)
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
scs@vax3.iti.org (Steve Simmons) (06/05/89)
In article <581@tiamat.fsc.com> jim@tiamat.fsc.com (Jim O'Connor) writes: :In article <398@sirius.ua.oz>, mrp@sirius.ua.oz (Mark Prior) writes: :> consider all mail to people at the Uni to be local and maybe some mail to :> other people outside as local (ie I want to use a local signature) so I :> would have a file like - :> :> *@*ua.oz.au :> person-alias :> group-alias :> :> Elm would then pattern match on these templates : :This would be a workable solution for "configuration file literate" users, :but most of my users still don't understand that .elm/elmrc and .newsrc :exist and/or what they are used for, much less a .elm/local-users file. True, but you as site admin can make it unnecesary for them. Suppose we have the following rules for pattern matching: first look in the users .elm/local-users file. If a definitive match is not found, look in /usr/local/lib/elm (or wherever you install the elm helpfiles and such) for a local-users file. Reasonable? On the same topic, the use of 'person-alias' and 'group-alias' above seems backwards (IMHO). Better to expand the aliases, then do the check. Steve Simmons Just another midwestern boy scs@vax3.iti.org -- or -- ...!sharkey!itivax!scs "Think of c++ as an object-oriented assembler..."
jim@tiamat.fsc.com (Jim O'Connor) (06/05/89)
In article <621@ispi.UUCP>, jbayer@ispi.UUCP (Jonathan Bayer) writes: > > Of all the suggestions that have come up, this is one of the better > ones. I needed an ego boost. Thanks :-) > 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 I don't really see this as being a major issue. In general, I'd say most people don't know everyone that is on a mailing list (except for maybe the administrator), and wouldn't know how to separate things. If you're refering to a distribution list (i.e. more than one recipient specified in the To: or Cc: headers), then I also don't think it's that big of a deal. Use the one which works out best. So what if some remote users occasionally get a local signature, or vice versa. Besides, if there was to be a different signature for different addresses in a distribution list, you would in essence, have different messages, and would (possibly) be defeating the purpose of using multiple recipients in the first place. > 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. This was the only thing I left out of my proposal. If it's not too difficult it would be nice to see something like SIGNATUREMENU = ON (or OFF) to toggle the use of the after editting signature append (MENU = ON) or to put the signature in the temp file before editting (MENU = OFF). ------------- James B. O'Connor jim@tiamat.fsc.com Filtration Sciences Corporation 615/821-4022 x. 651 *** Altos users unite! mail to "info-altos-request@tiamat.fsc.com" ***
jim@tiamat.fsc.com (Jim O'Connor) (06/05/89)
In article <1430@itivax.iti.org>, scs@vax3.iti.org (Steve Simmons) writes: > In article <581@tiamat.fsc.com> jim@tiamat.fsc.com (Jim O'Connor) writes: > :This would be a workable solution for "configuration file literate" users, > :but most of my users still don't understand that .elm/elmrc and .newsrc > :exist and/or what they are used for, much less a .elm/local-users file. > > True, but you as site admin can make it unnecesary for them. Suppose > we have the following rules for pattern matching: first look in the users > .elm/local-users file. If a definitive match is not found, look in > /usr/local/lib/elm (or wherever you install the elm helpfiles and such) > for a local-users file. Reasonable? If users become dependent on the system-wide file though, then everytime a user starts corresponding with someone from a new site or domain that he or she would like to be considered 'local', the user will call me and ask why it isn't working right, and if I would fix it so it will. Thus, the burden will end up on me. (Remember, they don't care about their own local-users file, so it won't do any good to tell them to edit that.) The menu option would be something they would easily see and be able to deal with. ------------- James B. O'Connor jim@tiamat.fsc.com Filtration Sciences Corporation 615/821-4022 x. 651 *** Altos users unite! mail to "info-altos-request@tiamat.fsc.com" ***
scs@vax3.iti.org (Steve Simmons) (06/05/89)
In article <589@tiamat.fsc.com> jim@tiamat.fsc.com (Jim O'Connor) writes: >In article <1430@itivax.iti.org>, scs@vax3.iti.org (Steve Simmons) writes: >> Suppose we have the following rules for pattern matching: first look in >> the users .elm/local-users file. If a definitive match is not found, >> look in /usr/local/lib/elm (or wherever you install the elm helpfiles >> and such) for a local-users file. Reasonable? > >If users become dependent on the system-wide file though, then everytime >a user starts corresponding with someone from a new site or domain that he >or she would like to be considered 'local', the user will call me and ask >why it isn't working right, and if I would fix it so it will. Thus, the >burden will end up on me. (Remember, they don't care about their own >local-users file, so it won't do any good to tell them to edit that.) No disrepect inteneded, but you are doing yourself and your users a disservice if you do as you describe. First, adding the particular site to the 'local' list may help that particular user, but will give `wrong' performance for other users sending to that system. Second, you must make it clear to the user requesting the change that he is requesting a *personal* modification which will affect *all* users, and you will not do that without the agreement of all users. Third, you must let the user know that *he* can customize his performance. Once you have done all these you have put the onus of making the personal customization on the user. Yes, he may refuse to do so. If he's like my users he'll give you grief. But that's a political/social issue with your users, and should not affect what technical decisions are made about elm. Steve Simmons Just another midwestern boy scs@vax3.iti.org -- or -- ...!sharkey!itivax!scs "Who the hell is Gloria Mundi, and why is she sick?"
pmm@mips.COM (Paul M. Moriarty) (06/05/89)
In article <1430@itivax.iti.org> scs@vax3.iti.org (Steve Simmons) writes: >In article <581@tiamat.fsc.com> jim@tiamat.fsc.com (Jim O'Connor) writes: >:> >:> Elm would then pattern match on these templates >: >:This would be a workable solution for "configuration file literate" users, >:but most of my users still don't understand that .elm/elmrc and .newsrc >:exist and/or what they are used for, much less a .elm/local-users file. > >True, but you as site admin can make it unnecesary for them. Suppose >we have the following rules for pattern matching: first look in the users >.elm/local-users file. If a definitive match is not found, look in >/usr/local/lib/elm (or wherever you install the elm helpfiles and such) >for a local-users file. Reasonable? This seems by far the most logical approach. I feel that most users (ie. >99%) have little need for more than two signatures and this approach seems to address the problem in a very straight-forward manner. What I like best about this approach is that my less sophisticated users are unaffected by it and my more sophisticated ones get something else to muck about with. :-) I'd like to see us reach some consensus on this issue soon as I feel we really have other problems and issues that need addressing as well and all this talk about signatures is drowning them in the noise. -- Paul M. Moriarty pmm@mips.com {ames,decwrl}!mips!pmm MIPS Computers Systems Not me baby, I'm too precious ....
karl@mstar.MorningStar.COM (Karl Fox) (06/07/89)
A simple and flexible scheme for dealing with signatures would be to have a line in the options screen for defining a command to execute to generate a signature (give it the message on stdin). It could be empty for no signature, "cat $HOME/.signature" for a fixed signature, or a special-purpose (shell?) program that could decide what to print based on the To: field. It might even be desirable for such a program to see destination addresses before aliases are expanded -- a mailing list might always need a certain signature that isn't appropriate for every day mail. This would also allow inserting the output in the (external) editor buffer, a feature that I really like. Besides, this way I could still use Elm and yet have `yow` output in my .signature! -- Karl Fox, Morning Star Technologies karl@MorningStar.COM
david@wubios.wustl.edu (David J. Camp) (06/08/89)
>>True, but you as site admin can make it unnecesary for them. Suppose >>we have the following rules for pattern matching: first look in the users >>.elm/local-users file. If a definitive match is not found, look in >>/usr/local/lib/elm (or wherever you install the elm helpfiles and such) >>for a local-users file. Reasonable? > Why not look in both files? The users personal file can take precedence if there is any conflict, and the system file would still be available when the user has just a few additions. If elm were really smart it would place the appropriate signature file in the edited file, and replace it with the newly appropriate signature file (modifying the edited file) when leaving the headers menu. It would be necessary to check for an exact match of the previous signature file against the last several lines of the file. It is probably good enough to just use the correct signature at the time of initial composition, since the user then has complete control over the message in his edit buffer. I still think an elmrc option whether to include the signature file in the edited message is best. -- Bitnet: david@wubios.wustl ^ Mr. David J. Camp Internet: david%wubios@wucs1.wustl.edu < * > Box 8067, Biostatistics uucp: uunet!wucs1!wubios!david v 660 South Euclid Washington University (314) 36-23635 Saint Louis, MO 63110