MAINT@DERRZE1.BITNET (Rainer M Woitok) (01/13/90)
Yesterday I installed 89-02-0A and was really impressed by the various enhancements and by the performance improvements achieved by using these index files. I'd nevertheless like to make some proposals, part of which arouse from my testing and playing with the new version, and part of which I'm carrying around for quite a while. The sequence in which I'll mention things is random and does not reflect any priority. 1. Message-Ids Since it is now possible to generate a unique message-id for each mail, it would perhaps be meaningful to display a message with a message-id only once in case it is cross posted to several lists. But since you'll see the mail only once, you will respond only once and thus to only one list. A way out would perhaps be to modify the REPLY ALL command in such a way that it would really pick up all addresses, even those in the X-To: or Comments: To: fields. In order to then bring this feature to a widespread use, the default for MESSAGE.ID should perhaps be changed to YES. 2. SENDER and FROM options for the LOG(D) command When you issue the LOG(D) command without parameters, the notebook to be used is determined from the various header fields which are scanned in a sequence specified via the LOGGING.PERSON option. This seems not enough for me. I have a PF-key set to LOGD#REPLY FROM, and using it I end up with the list mail I'm privately responding to being logged in, say, MAILBOOK NOTEBOOK while my response is logged in, say, SCHAFER NOTEBOOK. I would prefer my PF-key being set to LOGD (FROM#REPLY FROM TEXT in which case both items would end up in SCHAFER NOTEBOOK. I would recommend to interpret LOG (SENDER FROM as a request to log the item in both notebooks if they are different and to log it only once if they are not. Thus LOG (SENDER FROM may or may not behave like LOG(SENDER#LOG(FROM. 3. I'd like to see a SELECTD command When I read my incomming mail and encounter a subject I'm totally desinterested in, I'd like to select all items with that peculiar subject and to immediately mark them for deletion, so subsequent READs won't pick them up. Currently I have to use SELECT and then delete the items one by one by hand, since deleting items from a set of SELECTed menu lines is somewhat awkward, because the numeric parameters passed to the DISCARD command refer to the position in the main menu rather than to the position in the current selection. (By the way, since there are some commands which take as arguments the line number in the main menu, could there be another displayable column with exactly these numbers? I know, I know, I could turn the prefix on and set it to numeric, but five digits for that information seems a bit overdone.) 4. New sorting column STATUS (or similar) Since I can now sort according to multiple columns, I'd like also to be able to sort according to the status field, where either ' ' (old mail), '>' (new mail) or '-' (mail to be discarded) is displayed. Thus I could cleanly separate old from new mail. 5. Editing the header part This topic has already been discussed here, but I'd like to add my two cents: Since I'm working in a fullscreen environment, I'd like to make changes to the subject line by simply typing over it, without having to use a (line mode) SUBJECT command. Similarly I'd like to be able to add a Reply-To: line by simply duplicating the From: line and then changing the From: into a Reply-To:. I'd even like to be able to change recipients from a cc: status to a Bcc: or to a normal To: status and vice versa simply by typing over the corresponding fields, I'd like to correct a human name, drop a .BITNET suffix without having to clobber with INCLUDE and EXCLUDE. Finally I'd prefer the prefix-D command for omitting recipients. Couldn't MAIL postpone the creation of the BSMTP envelope until SEND is issued? Couldn't it even check for correct headers (if they were modified) and insert missing or drop extraeous commas from the To:, cc: and Bcc: lines? The manipulating of the headers currently is still sort of line mode oriented. (By the way, I even get the warning "Changes to the headers ..." when I enter a prefix-A command in the separator line containing all these equal signs.) 6. TIME.ZONES option My private TIMEZONE TABLE file contains slightly less than eighty entries of time zones I've encountered. Even if I omit rather strange ones, they clearly don't fit into a single line. Thus I'd prefer the TIME.ZONE option to specify a file containing the time zone definitions in the format "zone_name offset comment". Besides there are time zones which have offsets of some hours plus thirty minutes, for example CADT +10.5 Central Australian Daylight Time CAST +09.5 Central Australian Standard Time Does the TIME.ZONE option handle this? 7. What is the default of EXPAND.TABS? While file MAIL89 CHANGES states that the default be NO, PROFILE HELPMAIL claims it to be YES. Who is right? 8. Suboptimal use of screen width When I set MENU.FIELDS to FROM DATE SIZE SUBJECT, the subject column of the main menu does not use as much space as it could. The subject lines could be longer. Is there a way to do this? 9. Just for fun I had my main menu sorted according to the DATE column when I encountered a pair of mail items where the reply was listed ahead of the original question: Barry Hathaway 1/11/90*PROFS acknowledgements and reo Richard A. Schafer 1/11/90 PROFS acknowledgements and reo I checked the time stamps: Richard's was 13:13:57 CST, which is 19:13:57 UT and Barry's was 15:08:51 EDT which is 19:08:51 UT. So the software was correct: Fast-As-Lightning-Barry responded roughly five minutes before Richard asked. Sincerely Rainer .----------------------------------------------------------------------. | Rainer M. Woitok | Phone : (+49 9131) 85-7811,-7031 | | Regionales Rechenzentrum | e-Mail : MAINT@DERRZE1.BITNET | | Friedrich-Alexander-Universitaet | | | D-8520 Erlangen | | | West Germany | | '----------------------------------------------------------------------'
HATHAWA@GECRDVM1.BITNET (Barry Hathaway) (01/15/90)
Here's another wish list item: How about support for mailing lists. Right now list of addresses must be stored in the NAMES file which is limited in length. In addition, it forces you to create a list of nicknames and then define each nickname separately so you can use full names in your mail. What I would like to see is support for using a separate file of names in say a LISTSERV format: user1@node1 Full Name 1 -- user2@node2 Full Name 2 |-- FILE1 LIST etc. -- Then when sending mail you use the list by saying MAIL FILE1 (or maybe MAIL (LIST FILE1 ) This would allow the user to keep his mailing lists separate. A possible extension might be to include only the addressees in the BSMTP header and not in the RFC822 header.
VALDIS@VTVM1.CC.VT.EDU (Valdis Kletnieks) (01/16/90)
On Mon, 15 Jan 90 08:31:01 EDT Barry Hathaway said: >Here's another wish list item: >How about support for mailing lists. Right now list of addresses must be >stored in the NAMES file which is limited in length. In addition, it forces >you to create a list of nicknames and then define each nickname separately >so you can use full names in your mail. What I would like to see is support >for using a separate file of names in say a LISTSERV format: Another good reason for adding this - ever have a :list. that was over 250 chars long? Namefind can't deal with it too well - and yes, I *know* it should be a Listserv lsit, but we shouldn't force people to jump through hoops to make a rare mailing - the particular list I have is only used once every 2 months or so... Valdis
SCHAFER@RICEVM1.RICE.EDU (Richard A. Schafer) (01/16/90)
There's a simple solution to long lists (outside of the LISTSERV solution). :nick.MAJOR :list.minor1 minor2 :nick.MINOR1 :list.user1 user2... :nick.MINOR2 :list.user50 user51... Lists can be nested to any depth you'd like, with the obvious performance hit that an additional NAMEFIND is required for every level. The list I maintain for distribution of the code itself is :nick.MAILBOOK :list.continent1 continent2 ... :nick.continent1 :list.country1 ... :nick.country1 :list.region1 ... :nick.region1 :list.user1... Richard
NJG@CORNELLA.BITNET (Nick Gimbrone) (01/16/90)
On Mon, 15 Jan 90 15:38:56 CST Richard A. Schafer said: >There's a simple solution to long lists (outside of the LISTSERV solution). >:nick.MAJOR :list.minor1 minor2 >:nick.MINOR1 :list.user1 user2... >:nick.MINOR2 :list.user50 user51... And yet another is to use MAILER's distribution list support (hey, this is a VM MUA, so a VM MTA is a fine solution too). We use these rather heavilly here. For historical reasons we have supported something similar to that originally described (an external file which lists userids/nicknames to send mail to, though it didn't allow the "friendly user name" part). The mod to mailb00k is rather simple (just inserting another possible resolution for the 'name' being sent-to/included). We also have supported these same lists for sending files to NJE network recipients via a "sendfile/card/disk/print/<whatever you care to use as the transport>" front-end. It is pretty flexable, though slow (due to the use of NAMEFIND :-).
NADWL@HDEDH1.BITNET (Scott Ophof) (01/17/90)
On Fri, 12 Jan 90 14:06:31 CET Rainer M Woitok said: >Yesterday I installed 89-02-0A and was really impressed by the various >enhancements and by the performance improvements achieved by using >these index files. ... He done said a GOOD thing there! (as he usually does) >... >4. New sorting column STATUS (or similar) > Since I can now sort according to multiple columns, I'd like also to > be able to sort according to the status field, where either ' ' (old > mail), '>' (new mail) or '-' (mail to be discarded) is displayed. > Thus I could cleanly separate old from new mail. I have a REXX file (MAILSYNS XEDIT) to do that kind of things, like PRFON, which sets up the prefix area the way I want it. A SELECTD synonym for some code to pick up the column of "date:" on the first line of the menu, from which it can calculate the position of " ", ">", and "-", and then selectively display only the rest should then turn out to be a "trivial"(?) coding exercise, methinks... >5. Editing the header part > This topic has already been discussed here, but I'd like to add my > two cents: Since I'm working in a fullscreen environment, I'd like > to make changes to the subject line by simply typing over it, > without having to use a (line mode) SUBJECT command. Similarly I'd >... I second the motion. But what happens if Unsmart Normaluser by accident overtypes a header line, and doesn't remember what it was supposed to be? >9. Just for fun >... > Barry Hathaway 1/11/90*PROFS acknowledgements and reo > Richard A. Schafer 1/11/90 PROFS acknowledgements and reo > I checked the time stamps: Richard's was 13:13:57 CST, which is > 19:13:57 UT and Barry's was 15:08:51 EDT which is 19:08:51 UT. So > the software was correct: Fast-As-Lightning-Barry responded roughly > five minutes before Richard asked. Somebody's system TIME CLOCK set a "bit" wrong? Regards. Scott/
NJG@CORNELLA.BITNET (Nick Gimbrone) (01/17/90)
On Tue, 16 Jan 90 23:57:17 SET Scott Ophof said: >On Fri, 12 Jan 90 14:06:31 CET Rainer M Woitok said: >>4. New sorting column STATUS (or similar) >> Since I can now sort according to multiple columns, I'd like also to >> be able to sort according to the status field, where either ' ' (old >> mail), '>' (new mail) or '-' (mail to be discarded) is displayed. >> Thus I could cleanly separate old from new mail. >be a "trivial"(?) coding exercise, methinks... I think it is even more trivial to do it in the MAILB00K code (did it originally back in 7/89). Here's the 89.02.0A version (not yet on 0B, but this may also work there): ./ I 08910000 $ 8910001 1 07/17/89 20:36:28 /* Following select must have items in numeric order, sigh */ /*ml071*/ ./ I 08975950 $ 8975951 1 07/17/89 20:36:28 When(cursor.4 <= global.date_column.beg - 1) Then, cols = global.date_column.beg-1 global.date_column.beg-1 /* delete/unread flag */ /*ml071*/ What could be easier :-). >Somebody's system TIME CLOCK set a "bit" wrong? Jezz, we have 5 cpus in one room that often differ that that much (or or more :-).
NJG@CORNELLA.BITNET (Nick Gimbrone) (01/17/90)
On Fri, 12 Jan 90 14:06:31 CET Rainer M Woitok said: >3. I'd like to see a SELECTD command Why not just "select" the items then use "delete *" to get rid of them all... (last time I tried it this was a bit noisy, but perhaps that could be fixed :-). No need for a new command when two simple ones will do. >6. TIME.ZONES option > My private TIMEZONE TABLE file contains slightly less than eighty > entries of time zones I've encountered. Even if I omit rather > strange ones, they clearly don't fit into a single line. Thus I'd > prefer the TIME.ZONE option to specify a file containing the time You could just have the macro pick up the contents of the file and put it into a string to set the option (or have the option set via a variable set in your macro in any of (most likely) hundreds of ways...). No changes to the base mailbook code needed...
MAINT@CLVM.BITNET (Richard Seifert(IBM Systems Maintenance)) (01/17/90)
On Wed, 17 Jan 90 09:32:22 ECT Jim Blake said: >> >>5. Editing the header part >> This topic has already been discussed here, but I'd like to add my >> two cents: Since I'm working in a fullscreen environment, I'd like >> to make changes to the subject line by simply typing over it, >> without having to use a (line mode) SUBJECT command. Similarly I'd >>... >> > >Don't weaken, Richard. I do not want to hear the complaints from the >unsavvy users who clobbered their headers. > >Unless you wanted to make it yet another option. Say...HEADER.CLOBBER=OK > >jb Just to add my opinion, I sort of like Jim's idea. It is handy (at times) to be able to alter the header, if you know what you are doing. However, Joe-Fred User, who may or may not know what he is doing, should probably not be allowed to make the same alterations. Rich
AS0JEB@BINGVMA.BITNET (Jim Blake) (01/18/90)
> >5. Editing the header part > This topic has already been discussed here, but I'd like to add my > two cents: Since I'm working in a fullscreen environment, I'd like > to make changes to the subject line by simply typing over it, > without having to use a (line mode) SUBJECT command. Similarly I'd >... > Don't weaken, Richard. I do not want to hear the complaints from the unsavvy users who clobbered their headers. Unless you wanted to make it yet another option. Say...HEADER.CLOBBER=OK jb
MICHAEL@UTORONTO.BITNET (Michael Wagner) (01/18/90)
>>Somebody's system TIME CLOCK set a "bit" wrong? >Jezz, we have 5 cpus in one room that often differ that that much (or >or more :-). Which seems like a good reason, to me, not to use date/time as a sort field for the "intuitive" order, which is who replied to whom. Michael
JAUUS@CUVMB.BITNET (jbaltz) (01/18/90)
On Wed, 17 Jan 90 11:09:12 EDT Richard Seifert(IBM Systems Maintenance) said: > > Just to add my opinion, I sort of like Jim's idea. It is handy (at times) >to be able to alter the header, if you know what you are doing. However, >Joe-Fred User, who may or may not know what he is doing, should probably not >be allowed to make the same alterations. > Better yet would be to have a variable (either NOVICE or EXPERT, either one) that would a) allow you to edit headers b) shorten the final message to something like: purge nn msgs? ynm &c. I'm sure if I sat down to think I could come up with more :) DISCLAIMER: I don't speak for Columbia, and Columbia doesn't speak for me //jbaltz Jerry B. Altzman jbaltz@cunixf.cc.columbia.edu jauus@CUVMB NEVIS::JBALTZ (HEPnet) +1 212 854 8058
MAINT@DERRZE1.BITNET (Rainer M Woitok) (01/18/90)
On Tue, 16 Jan 90 23:57:17 SET Scott Ophof said: >On Fri, 12 Jan 90 14:06:31 CET Rainer M Woitok said: >> ... >> I checked the time stamps: Richard's was 13:13:57 CST, which is >> 19:13:57 UT and Barry's was 15:08:51 EDT which is 19:08:51 UT. >> ... > >Somebody's system TIME CLOCK set a "bit" wrong? Not necessarily. Look at Barry's time zone. I says "EDT", but it probably should still read "EST" (we're only in January now). This points to a general deficiency of the way, computer vendors are dealing with the computer system clock and time zone. Almost all computers we had so far had to be brought down and re-IPLed to change the system clock, and our IBM even needed a system generation twice a year to change the time zone information (we now have installed a mod, I obtained from John F. Chandler <PEPMNT@CFAAMP> over the net, which does the change of time and time zone twice a year automagically). Sincerely Rainer .----------------------------------------------------------------------. | Rainer M. Woitok | Phone : (+49 9131) 85-7811,-7031 | | Regionales Rechenzentrum | Fax : (+49 9131) 30 29 41 | | Friedrich-Alexander-Universitaet | Telex : d 629 755 tf erl | | D-8520 Erlangen | e-Mail : MAINT@DERRZE1.BITNET | | West Germany | | '----------------------------------------------------------------------'
MAINT@DERRZE1.BITNET (Rainer M Woitok) (01/18/90)
On Tue, 16 Jan 90 22:31:57 EST Nick Gimbrone said: >On Fri, 12 Jan 90 14:06:31 CET Rainer M Woitok said: >>3. I'd like to see a SELECTD command >Why not just "select" the items then use "delete *" to get rid of them >all... Neither does HELP DISCARD or HELD DELETE mention "*" as a possible argument nor does my 89-02-0A version support it. If I issue "DISCARD *" after having selected some items, I get a message to the effect of Value "*" not allowed. > ... >>6. TIME.ZONES option >> My private TIMEZONE TABLE file contains slightly less than eighty >> entries of time zones I've encountered. Even if I omit rather >> strange ones, they clearly don't fit into a single line. Thus I'd >> prefer the TIME.ZONE option to specify a file containing the time >You could just have the macro pick up the contents of the file and put >it into a string to set the option (or have the option set via a >variable set in your macro in any of (most likely) hundreds of >ways...). No changes to the base mailbook code needed... For the sake of argument lets assume only 50 time zones (there should be approximately 24 round the globe (standard) plus the same 24 during the summer (daylight) plus some widespread synonyms like UT for GMT etc). Then you have 50 * 3 = 150 chars for the time zone abbreviation 50 * 1 = 50 blanks to separate zone name from value -1 + 50 * 1 = 49 blanks to separate value from next zone 10 * 1 = 10 digits for positive offsets < 10 4 * 2 = 8 digits for positive offsets > 9 (offset may be as big as 13) 10 * 2 = 20 digits for negative offsets < 10 4 * 3 = 12 digits for negative offsets > 9 ----- 299 characters needed for the value This number is reduced a bit because some time zone abbreviations only use two characters, but there are less than 44 two character time zone abbreviations in my file. Since GLOBALV imposes a limit of 255 characters on the value's length, SETMAIL will somehow or other choke on it or at least truncate it. So, as far as I see, there is currently no way to do that (let alone hundreds). Sincerely Rainer .----------------------------------------------------------------------. | Rainer M. Woitok | Phone : (+49 9131) 85-7811,-7031 | | Regionales Rechenzentrum | Fax : (+49 9131) 30 29 41 | | Friedrich-Alexander-Universitaet | Telex : d 629 755 tf erl | | D-8520 Erlangen | e-Mail : MAINT@DERRZE1.BITNET | | West Germany | | '----------------------------------------------------------------------'
NADWL@HDEDH1.BITNET (Scott Ophof) (01/18/90)
On Wed, 17 Jan 90 09:32:22 ECT Jim Blake said: >>5. Editing the header part >>... >Unless you wanted to make it yet another option. Say...HEADER.CLOBBER=OK That would also mean adding the option: DEFAULT.RESPONSIBLE.IF.ERRORS=userid() where no nicknames or nodeids would be accepted, and any other value than the invoker's would result in a (reverse) highlighted, blinking, beeping screen... Regards. Scott/
NADWL@HDEDH1.BITNET (Scott Ophof) (01/18/90)
On Wed, 17 Jan 90 15:43:11 CET Rainer M Woitok said: >On Tue, 16 Jan 90 22:31:57 EST Nick Gimbrone said: >>On Fri, 12 Jan 90 14:06:31 CET Rainer M Woitok said: >> ... >>>6. TIME.ZONES option >>>... >For the sake of argument lets assume only 50 time zones (there should >be approximately 24 round the globe (standard) plus the same 24 during >the summer (daylight) plus some widespread synonyms like UT for GMT >etc). Then you have >... > 299 characters needed for the value >... >abbreviations in my file. Since GLOBALV imposes a limit of 255 >characters on the value's length, SETMAIL will somehow or other choke >... So put the standard zones in one global variable, and the daylight savers in another? Regards. Scott/
MAINT@DERRZE1.BITNET (Rainer M Woitok) (01/18/90)
On Wed, 17 Jan 90 09:32:22 ECT Jim Blake said: >Don't weaken, Richard. I do not want to hear the complaints from the >unsavvy users who clobbered their headers. > >Unless you wanted to make it yet another option. Say...HEADER.CLOBBER=OK I can't quite see your point. As I understand it, before release 89-02- 0A it was always possible to clobber your headers. You did get a warning message, but only after the headers were destroyed. Did this former possibility of clobbering the headers cause any serious problems? By the way, if you would do it in a very noble way, the program could save the original headers before you clobber them, check them before really sending the mail (of course only if they were changed at all) and refuse to send when the headers are rotten. It'd then be up to you to unclobber the headers, possibly by typing something to the effect of RECOVER or UNDO to again get the original headers. Sincerely Rainer .----------------------------------------------------------------------. | Rainer M. Woitok | Phone : (+49 9131) 85-7811,-7031 | | Regionales Rechenzentrum | Fax : (+49 9131) 30 29 41 | | Friedrich-Alexander-Universitaet | Telex : d 629 755 tf erl | | D-8520 Erlangen | e-Mail : MAINT@DERRZE1.BITNET | | West Germany | | '----------------------------------------------------------------------'
GKMCU@CUNYVM.BITNET (Geert K. Marien) (01/19/90)
>On Tue, 16 Jan 90 22:31:57 EST Nick Gimbrone said: >>On Fri, 12 Jan 90 14:06:31 CET Rainer M Woitok said: >>>3. I'd like to see a SELECTD command >>Why not just "select" the items then use "delete *" to get rid of them >>all... > >Neither does HELP DISCARD or HELD DELETE mention "*" as a possible >argument nor does my 89-02-0A version support it. If I issue "DISCARD >*" after having selected some items, I get a message to the effect of >Value "*" not allowed. I have a mod for 89.01 version 0B that allows a DELETE * (and also an UNDELETE *) option. It works just like (un)DELETE 1:*. The price is right. /Geert
CMS2@ETSU.BITNET (Bill Williams) (01/19/90)
On Wed, 17 Jan 90 09:32:22 ECT Jim Blake said: >>5. Editing the header part >> This topic has already been discussed here, but I'd like to add my >> two cents: Since I'm working in a fullscreen environment, I'd like >> to make changes to the subject line by simply typing over it, >> without having to use a (line mode) SUBJECT command. Similarly I'd >>... >Don't weaken, Richard. I do not want to hear the complaints from the >unsavvy users who clobbered their headers. I don't mind the BSMTP envelope idea, but I now *need* an option to do a "temporary" CHECK.LOCAL.ID=NO for "just this mail item". OR perhaps a 'pc: userid' like the cc: and bcc: options which indicates a pseudo-id instead of the option to override the CHECK.LOCAL.ID. It is necessary sometimes to MAIL to a pseudo local user -- for example: MAIL C_CLASS where C_CLASS is not really a local userid but rather a LIST defined in our MAILER (r2.05). Yes, I can set my CHECK option to NO, do the MAIL and then set my CHECK back to YES, but the main use of the MAILER LIST capability is for (*gasp*) users. Since users are the very ones with the expertise to really trash the headers by editing them, they are the very ones I don't want to be able to 'edit' the headers. And they need to be watched over in events where they are actually misspelling the name of the target and ending up with a genuinely wrong destination; this means that they need to do something deliberate in order to *know* that they're specifying a pseudo user -- the list. Or perhaps some special :tag.value in the names file for the given LIST to tell MAIL that this user's Ok. Maybe a :node. with non-valid node name characters to indicate that this is a local pseudo user? Any "easy to set up for the end user" (we're talkin faculty, here) method for using MAIL to talk to the MAILER defined LIST userid would be helpful. Or is the best thing to simply create dummy CMS userids for each list-name in MAILER and just let the rough side drag? :-) BTW: I'm OCO for MAIL/MAILBOOK. ---------- B.R.Wms
MAINTCMS@PUCC.BITNET (John Wagner) (01/19/90)
A nice change would be to always support 'POSTMASTER' no matter what the check.local.id value is set to. John Wagner