Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!uunet!osh3!chip From: chip@osh3.OSHA.GOV (Chip Yamasaki) Newsgroups: comp.mail.elm Subject: Re: Hey Syd, here's a couple of ideas! Message-ID: <1991Jun23.042040.11448@osh3.OSHA.GOV> Date: 23 Jun 91 04:20:40 GMT References: <1991Jun20.044510.781@osh3.OSHA.GOV> <1991Jun20.141539.16160@DSI.COM> Organization: U.S. D.O.L - Occupational Safety & Health Admin. Lines: 105 In <1991Jun20.141539.16160@DSI.COM> syd@DSI.COM (Syd Weinstein) writes: >chip@osh3.OSHA.GOV (Chip Yamasaki) writes: >>I'll look at it some more and see how the Elm community and developers >>react to a suggestion or two. >I have been told I react poorly to suggestions...... Who says! This looks like a pretty good response to me. >Elm does not have that type of menu currently, but a character based >point and shoot menu is under consideration for the character based >front-end for Elm 3.0. Great. Like I said, I like the current interface. But the less experienced users are crying for the P&S. An option to switch between the two would be a pain to develop and maintain, but would be nice. >>Another complaint is no binary attachments. >This one has been under discussion since 2.2 was being developed. We >even, internally, floated a proposal about it. No one did anything >with it, partly because the AT&T method, Content-Type:/Content-Length: >for attachments didn't go anywhere and become a 'global' standard, >and at that time, not too much need, compared to now. Plus, at that >time, most mail transports were not 8 bit clean, so the best >we could do would be a uuencoded attachment.... But that's just what I was suggesting, a uuencoded attachment. It didn't adhere to any standards, but there were a few nice things about it. 1. It would survive most MTA's (except for size limitations). 2. It could be unpacked almost anywhere. 3. Attachments could be accessed even by non-Elm'ers. 4. It should be a simple addition. As I said. The attach command could be offered on the same menu with (s)end/(f)orget, and the files could be attached just before release to the MTA. Then the only other things to worry about would be a "(F)ile attachment" command on the main menu, and stripping out the attachment and replacing it with "Attached file:" at the end of the letter before passing it on to the pager/editor. >>Finally, a nice touch is their editor. I've seen lots of callsfor a >>simple editor, but no great responses. >I would love a 'simple' editor to distribute with Elm as a contributed >product. I am even threatened myself to 'write one' but I don't really >have the time if I am to get 2.4 out. I also view this as a major >shortcoming. Yeah, it seems that nobody's got the guts or time (including me) to write such an editor. I recently saw somebody in the PC binaries group flame another person because the Pascal based editor they posted didn't have enough features. Sometimes people forget that there are some entry level users out there to support. >>Another thing I have yet to see is a macro language or API for Elm. >I need some convincing here that an Elm macro language would really >do something and buy you something.... As for API, I am unsure >how that would be used.... I need some 'education' there. Well, with a full featured macro language you could probably do away with most of the wonderful little filters and daemons you include with Elm yet leave the functionality. People could write scripts to THOROUGHLY filter their mail based on combinations of message content, sender, user defined headers, and other combinations of conditions. Another use for a macro language would be to create a mail server based on Elm. I'm sure there are lots of other uses for a macro language and you'll probably hear several from the netters. On the other hand, and API would be nice too. In fact, you could skip the macro language if you had an API. I think in many macro langauges the developers include lots of features that do not deal with the application at hand, but rather things that have to do with macro programming or application building. For example, with a macro language you might have commands to prompt for input, compare logical expressions, display output, etc. With an API you could skip all of this. Let the user get these features from whatever language they are accessing the API from (ASM, C, Perl, etc.), and just concentrate on the mail handling features. Considering Elm is not a commercial product I think all of this is a bit much to ask. Don't think I'm being unreasonable without realizing it. A nice approach to just about all these suggestions would be an Elm engine. This would be a kind of E-Mail UA engine that would form the heart of Elm. Mid-level features like "parse an address" or "get message sender", and high-level features like "mail a message" and "save a message" could be functions of the API. Then the current Elm interface could be separated into a replaceable front-end that would access that API to function exactly like it does now. Then when pesky users like me ask for a feature in the interface you could just say "add it to the interface yourself" or "come up with your own plug-and-play Elm interface". This way the interface could be modified and compatibility would only suffer at the interface. The mail handling features and heart of the application would remain the same. As I said. I know this is all unreasonable, but I thought I'd bring it up. Judging by the number of responses (I haven't read them yet) I'd say that it stirred some discussion. Sorry :-). Thanks! -- -----------------------+--------------------------------------------------- Charles "Chip" Yamasaki| The opinions expressed here are my own and are not chip@oshcomm.osha.gov | supported or even generally accepted by OSHA. :-) -----------------------+---------------------------------------------------