simsong@media-lab.MEDIA.MIT.EDU (Simson L. Garfinkel) (11/30/90)
Hi. I'm building a new News reader for the NeXT as part of my PhD research.
This news reader will also have the ability to post.
One of the things that I've been playing around with is the idea of posting
Rich Text to newsgroups --- in particular, to comp.sys.next.
Rich Text is a Microsoft format for embedding font information in
regular ASCII. If you were reading this document with Rich Text turned
on, then {\bf this would be bold}.
It's actually a little more complicated than that, though, because \
each line of a rich text paragraph must end with an "escaped" carriage \
return, like the ones in this paragraph, so that you know they are \
really carriage returns. Normally, the Rich Text interperter ignores \
carriage returns.
Rich text is mostly readable without computer assistance, unlike the
compressed, tarred, and uuencoded stuff that NeXT uses for delta-mail.
Of course, if we wanted to go all the way, would could do full delta-mail
for the newsgroup, and let people put voice and other sorts of things
into their netnews messages.
One of the things that has been suggested is embedding font information
in the header, but this would be difficult, actually, and of questioanble
worth. Another idea is to include monofont at the top of the message
and follow it with uuencoded, compressed, rich text at the end. This would
let people with standard "rn" read the message. My NeXT reader, of course,
would trash the monofont part and would just show the rich text, (after
first uudecoding and uncompressing it.)
What do people think?wln@cunixb.cc.columbia.edu (William L Nussbaum) (11/30/90)
In article <4196@media-lab.MEDIA.MIT.EDU> simsong@media-lab.MEDIA.MIT.EDU (Simson L. Garfinkel) writes: >Hi. I'm building a new News reader for the NeXT as part of my PhD research. >This news reader will also have the ability to post. > >One of the things that I've been playing around with is the idea of posting >Rich Text to newsgroups --- in particular, to comp.sys.next. > >Rich text is mostly readable without computer assistance, unlike the >compressed, tarred, and uuencoded stuff that NeXT uses for delta-mail. >Of course, if we wanted to go all the way, would could do full delta-mail >for the newsgroup, and let people put voice and other sorts of things >into their netnews messages. > >One of the things that has been suggested is embedding font information >in the header... > ...My NeXT reader, of course, >would trash the monofont part and would just show the rich text, (after >first uudecoding and uncompressing it.) How about a headerline: Formats: Text, rnRTF, DeltaMail in the order the pieces are in the message. DeltaMail probably isn't a great idea, given the sort of bulk things which may be enclosed in DeltaMail require, but for every-once-in-a-while it's a reasonable idea. I think an extension to RTF to allow you to specify ranges would be needed for reasonable mail. That is, for this message, instead of {\bHow about a headerline:} you would see: {\b{\start\linesfromhdr19\char1\end\char23}} (though the specifiers would be much shorter. They're long here for purposes of demonstration). \linesfromhdr (or \lfh or whatever) would refer to the n'th line from (and including, in my example; a change to 0-base may or may not be appropriate...) the first non-blank line following the header. Mail might begin with standard text, have an {\rtf999{allthertf}} group after the text, and DeltaMail format, when necessary, should probably be the last rnRTF group and be specified as {\deltamail ....all the UUENCODE data... }. This kind of a structure would also supply a reasonable extended news format for those people who wanted to implement extended news for another GUI... ...just some thoughts. Remember that the compactness of these messages is a relatively significant issue, and that many readers will not have a capable news reader, and will not want to read RTF or UUENCODE data. This issue alone may prove somewhat difficult; any extension (except maybe ^L before the RTF block begins) will be beyond the knowledge of current news readers; many readers don't even understand the ^L's, apparently; for these, I'm not sure what approach you'd take. LaterOn -Lee | William Lee Nussbaum, Jr. | wln@cunixb.cc.columbia.edu
gillies@m.cs.uiuc.edu (11/30/90)
As a first crack do not encode the RTF information at all. Just put
the RTF information at the end of the message in plaintext, using
character ranges to specify formatting attributes. This is similar to
the way Xerox PARC's Cedar WYSWYG editor works. So for instance, put:
12,364 {/b }
Where the {/b is logically inserted after the 12th character in the
text stream, and the } is logically inserted after the 364'th
character.
If you do not compress this information, then you can put together a
pieces data structure (linked list of pointers to text fragments)
describing the entire message, in RTF, very fast. This allows the
text stream to be treated as a read-only data structure in memory.
The RTF can then be read as a stream of characters by cdr'ing down the
pieces data structure.
Later on, you might compress/binhex the data. By sorting the RTF
tokens in increasing appearance number, it might later be possible to
decompress & unpack the binhex at the same time the message is being
displayed, to get good performance. All you need to do is show the
first page almost immediately (in most cases), and the user will
probably be happy.
This also facilitates fast searches on the text stream.
The overhead of sending both a plaintext and an RTFtext message
through UUCP is unacceptable
Don W. Gillies, Dept. of Computer Science, University of Illinois
1304 W. Springfield, Urbana, Ill 61801
ARPA: gillies@cs.uiuc.edu UUCP: {uunet,harvard}!uiucdcs!gilliesmoose@svc.portal.com (12/01/90)
In article <4196@media-lab.MEDIA.MIT.EDU> simsong@media-lab.MEDIA.MIT.EDU (Simson L. Garfinkel) writes: >Hi. I'm building a new News reader for the NeXT as part of my PhD research. >This news reader will also have the ability to post. > >One of the things that I've been playing around with is the idea of posting >Rich Text to newsgroups --- in particular, to comp.sys.next. I think it's a bad idea. For a mailing list, NeXT attachments and RTF stuff is appropriate since everyone says they want it. For a public forum, it's a real pain to the people that don't want to use some special software. -- Michael Rutman | moose@svc.portal.com Cubist | makes me a NeXT programmer Software Ventures | For Your Eyes Only Public Key
cyliax@dynamo.ecn.purdue.edu (Ingo Cyliax) (12/01/90)
How about starting a NeXT mailing list where we can use attachments and then have a machine gateway them into comp.sys.next. This gateway could then convert message into some kind of ascii representation of the original (i.e. dropping the graphics etc.), or maybe it could only gateway messages that are plain text. -ingo -- /* Ingo Cyliax ECN, Electrical Engineering Bldg. * * cyliax@ecn.purdue.edu Purdue University, W. Lafayette,IN 47907 * * ing@cc.purdue.edu Work: (317) 494-9523 * * cyliax@pur-ee.UUCP Home: (317) 474-0031 */
jacob@gore.com (Jacob Gore) (12/02/90)
/ simsong@media-lab.MEDIA.MIT.EDU (Simson L. Garfinkel) / Nov 29, 1990 / > I'm building a new News reader for the NeXT as part of my PhD research. > This news reader will also have the ability to post. > One of the things that I've been playing around with is the idea of posting > Rich Text to newsgroups --- in particular, to comp.sys.next. Hmm... > Rich Text is ... ... standard feature on the NeXT, can easily be created with Edit. > Rich text is mostly readable without computer assistance, That's a matter of opinion... > unlike the > compressed, tarred, and uuencoded stuff that NeXT uses for delta-mail. This, of course, is unreadable. However, there is a good reason to uuencode RTF before sendint it out through the networks: to take full advantage of it, one takes full advantage of the fonts, which sticks 8-bit characters into the file. For example, the en dash would be used to indicate range instead of "-", and the em dash would be used for the dash instead of "--". However, both of those are in the upper half of the byte. The problem is that many network mail (and UUCP) protocols are 7-bit, and they strip the 8th bit off (or use it for parity). Thus, "pp. 12-15", where the "-" is the en dash, comes out something like "pp. 12115". > Of course, if we wanted to go all the way, would could do full delta-mail > for the newsgroup, and let people put voice and other sorts of things > into their netnews messages. Yeah, but we'll probably need to get a different distribution. Most Usenet sites will probably drop comp.sys.next if its traffic becomes that of a binary group (which is what posting voice and images will do). > One of the things that has been suggested is embedding font information > in the header, but this would be difficult, actually, and of questioanble > worth. It may not be difficult to factor out all the markup information into a separate section. If that can be done, the header is as good a place to store that section as any. > Another idea is to include monofont at the top of the message > and follow it with uuencoded, compressed, rich text at the end. This would > let people with standard "rn" read the message. My NeXT reader, of course, > would trash the monofont part and would just show the rich text, (after > first uudecoding and uncompressing it.) If you do that, you may as well have two parallel newsgroups. Have each doubly-encoded message look like it's cross-posted, and read the RTF group first. This way, sites can choose not to receive the encoded stuff. Some general comments now: 1. Eric Raymond's News 3.0 package (formerly known as TMNN, Teenage Mutant Ninja Netnews, so named before the little green morons became the hype of the world). It has libraries and character-stream clients that does most of the message access work for you, and the same interface is used for local and NNTP access. Save yourself a ton of work, contact him at eric@snark.thyrsus.com. 2. It annoys me that everybody, including NeXT, is going out of their way to improve the appearance of electronic communications, while sacrificing user's editing habits. I've been bitching about being unable to use Emacs to create messages ever since I started using the machine, in 0.8 days. Result from NeXT: none. Result from me: I don't use NeXT Mail. I have MMDF installed instead of sendmail, and I use msg to read and write mail. Msg respects users' preferences for various editors, while Mail sticks you with the Text object. No matter how spiffy your newsreader is, I'm not likely to use it unless it lets me use Emacs to compose my messages. Jacob -- Jacob Gore Jacob@Gore.Com boulder!gore!jacob
louie@sayshell.umd.edu (Louis A. Mamakos) (12/04/90)
In article <130125@gore.com> jacob@gore.com (Jacob Gore) writes: >2. It annoys me that everybody, including NeXT, is going out of their way to >improve the appearance of electronic communications, while sacrificing >user's editing habits. I've been bitching about being unable to use Emacs >to create messages ever since I started using the machine, in 0.8 days. >Result from NeXT: none. Result from me: I don't use NeXT Mail. I have >MMDF installed instead of sendmail, and I use msg to read and write mail. >Msg respects users' preferences for various editors, while Mail sticks you >with the Text object. I don't use NeXT Mail either. I have MH installed instead of the Mail Application, and use MH and emacs to read and write mail. MH respects users' preferences for various editor, while Mail sticks you with the Text object. >No matter how spiffy your newsreader is, I'm not likely to use it unless it >lets me use Emacs to compose my messages. Ditto. I'd be a happy camper if Emacs could do something useful with RTF so I could trash Edit completely. I can't use Emacs to compose my messages (or any other editor, at my choice, for that matter), then I won't use the spiffy Mail application. I rather like the approach that XMH uses: a nice graphical/visual front-end to a mail system which is still useful when calling in from home to check your mail. This capability is an *absolute* necessity, not to mention the much greater functionallity available in MH for organizing messages into folders and selecting messages with complex and flexible mechanisms. With the Mail App, you're stuck with what you get. Unusable interface when not at the screen, and an incompatible file format that thwarts your attempts to use "less powerful" tools. "Lip service" indeed. louie
mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) (12/04/90)
As the author of MailManager, the good mail reader for the NeXT (not
to be confused with the NeXT system administration program by that
name -- I had the name first from winter 1989), I am very interested
in the comments from Messrs. Gore and Mamakos regarding the desire to
have an EMACS interface instead of the Text object.
At the present time, MailManager uses the Text object, but only
because there is no clean interface between NeXTstep and the
traditional editors (EMACS, vi, etc.). I would like to change this
state of affairs, but I feel that most of the responsibility lies with
NeXT.
That is, I feel that NeXT should provide this functionality as part of
the Appkit and that application developers should not be required to
implement custom NextStep EMACS or vi interfaces. I don't think that
customers should have to do NeXT's work for them in providing a basic
functionality.
I've been told repeatedly that there are "EMACS keys" for the Text
object in 2.0, but I doubt that it is anything like a complete EMACS.
I would like to have a true EMACS interface in MailManager. My
requirements is that it:
1) must not depend upon any non-NeXT-supplied software (in other
words, I can't call the Emacs NextStep application since it is
not distributed by NeXT)
2) must be in a View in a window I own. I allow many simultaneous
windows of many different types, each of which may have editing
going on.
3) must allow cut/paste between windows. Should allow mouse-based
editor operations *in addition to* normal EMACS/vi/whatever.
4) RTF editing is nice, but not essential; it would be alright as an
interim measure to restrict this to fixed-width single font texts.
Ideally, I would like a replacement to the Text object that interacts
with EMACS, and in which each separate invocation talks to a separate
EMACS buffer. Something similar should be done for vi, but I'm not a
vi hacker so I don't know what that would entail.
Can we as a community get together a reasonable desiderata of what we
need and give it to NeXT as a "must implement"? I can't believe that
we really want to keep on reinventing the wheel on giving users a
decent editor interface in our applications.
Footnote to Mr. Mamakos: MailManager addresses the compatibility
issues you raise. Contact me by e-mail if you're interested. Don't
worry about "lip service" kinds of silliness -- MailManager works hard
to provide function, not "cute."
_____ | ____ ___|___ /__ Mark ("Gaijin") Crispin "Gaijin! Gaijin!"
_|_|_ -|- || __|__ / / R90/6 pilot, DoD #0105 "Gaijin ha doko?"
|_|_|_| |\-++- |===| / / Atheist & Proud "Niichan ha gaijin."
--|-- /| |||| |___| /\ (206) 842-2385/543-5762 "Chigau. Omae ha gaijin."
/|\ | |/\| _______ / \ FAX: (206) 543-3909 "Iie, boku ha nihonjin."
/ | \ | |__| / \ / \MRC@CAC.Washington.EDU "Souka. Yappari gaijin!"
Hee, dakedo UNIX nanka wo tsukatte, umaku ikanaku temo shiranai yo.louie@sayshell.umd.edu (Louis A. Mamakos) (12/04/90)
In article <12266@milton.u.washington.edu> mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) writes: >That is, I feel that NeXT should provide this functionality as part of >the Appkit and that application developers should not be required to >implement custom NextStep EMACS or vi interfaces. I don't think that >customers should have to do NeXT's work for them in providing a basic >functionality. This is an interesting thought; it is, perhaps, a bit more ambitious than I would have thought necessary for a mail application, but certainly would be welcome. >I would like to have a true EMACS interface in MailManager. My >requirements is that it: > 1) must not depend upon any non-NeXT-supplied software (in other > words, I can't call the Emacs NextStep application since it is > not distributed by NeXT) > 2) must be in a View in a window I own. I allow many simultaneous > windows of many different types, each of which may have editing > going on. > 3) must allow cut/paste between windows. Should allow mouse-based > editor operations *in addition to* normal EMACS/vi/whatever. > 4) RTF editing is nice, but not essential; it would be alright as an > interim measure to restrict this to fixed-width single font texts. Good set of goals, sounds very difficult to provide without a great deal of work. In fact, this sounds like the basis for a fine replacement for Edit for those Emacs weenies amoung us. I find that my fingers are too well trained in Emacs to make effective use of Edit, other than to browse RTF file. Converting from Emacs to Edit is not an option since I use Emacs varients on *all* the other systems that I edit text on. >Ideally, I would like a replacement to the Text object that interacts >with EMACS, and in which each separate invocation talks to a separate >EMACS buffer. Something similar should be done for vi, but I'm not a >vi hacker so I don't know what that would entail. The rumours that I've heard of how Emacs version 19 from the FSF will work might make it more appropriate than the existing version of emacs, but we'll only know that for sure once its available. >Can we as a community get together a reasonable desiderata of what we >need and give it to NeXT as a "must implement"? I can't believe that >we really want to keep on reinventing the wheel on giving users a >decent editor interface in our applications. This is an excellent idea. Perhaps now that 2.0 is released and the new hardware is on its way, they'll have time do deal with stuff like this. >Footnote to Mr. Mamakos: MailManager addresses the compatibility >issues you raise. Contact me by e-mail if you're interested. Don't >worry about "lip service" kinds of silliness -- MailManager works hard >to provide function, not "cute." Mark, I've played with earlier versions of MailManager. I didn't use it at the time because of the mail file format compatibility issues that I mentioned before. I understand that the latest version addresses this point, and I have fetched it but have not had the time yet to install it and give it a try. I will definately have to do so. I really liked what I saw before, but couldn't give up compatibility with MH. Perhaps we need a little discussion of what people would like to see in a Mail application. The reason that I hold so tightly to MH is because of its tool based approach; many small programs to format, display, select and manage mail messages. MH messages are just UNIX files, and "folders" are directories. I have shell aliases, scripts and other tools to help manage the dozens of messages that I receive every day. Without a similar capability in a visually based mail application, my productivity goes *DOWN* rather than being improved. That's why is suggested that mail applications have to be compatible with existing mail storage formats. If I can't have the extension capabilities in the Mail application, then at least I can invoke shell scripts and other processes to cull incoming mail, seperate it in to multiple folder or message sequences and highlight the messages that I MUST SEE. Then perhaps I can use the Mail application to present them to me a bit more pleasently. Having little pictures of the sender doesn't really help ME all that much; I either already know what the person looks like who works in my organization or they are strangers and don't have any "faces" online. Is that *really* an aid to productivity? How about this "lip server" that I mentioned in a previous message? It's pretty spiffy, but before including that in an application, there are many more critical feature that I need, like the file inclusion capability. The Mail application is cute and usable for a great many folks. But is it definately *not* a heavy duty tool usable for some of us that deal with large volumes of mail daily as a routing part of our work. louie
glenn@heaven.woodside.ca.us (Glenn Reid) (12/05/90)
In article <130125@gore.com> jacob@gore.com (Jacob Gore) writes: >user's editing habits. I've been bitching about being unable to use Emacs >to create messages ever since I started using the machine, in 0.8 days. >Result from NeXT: none. Result from me: I don't use NeXT Mail. I agree with you about Emacs key bindings. But NeXT Mail *does* support Emacs-style editing, which is almost as good, and in many ways better, than full Emacs (unless it's the macros and programmability and power that you're after, and not just the key combinations that are hard-wired into your fingers). In 1.0 it required a cryptic preference to be set ("dwrite Mail KeyBindings YES"), but in 2.0 it's right there in the Preferences panel (under "expert" features). -- Glenn Reid RightBrain Software glenn@heaven.woodside.ca.us PostScript/NeXT developers ..{adobe,next}!heaven!glenn 415-851-1785
mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) (12/05/90)
In article <1990Dec4.141122.1679@ni.umd.edu> louie@sayshell.umd.edu (Louis A. Mamakos) writes: >Good set of goals, sounds very difficult to provide without a great >deal of work. In fact, this sounds like the basis for a fine >replacement for Edit for those Emacs weenies amoung us. Why do you think that I want NeXT to do it? It is a lot of work, and my boss isn't paying me to do it (U of W has no particular commitment to NextStep, and in fact there is still some skepticism about NeXT's long-term viability). Just about the only way I would do it for NeXT is if I got a free system out of it plus enough cash to cover the tax consequences... >[your mail program desiderata] Thank you for these comments. MailManager has a somewhat different philsophy in dealing with mailboxes than MH -- note that you really can't go between MH and /usr/ucb/Mail -- but provides a lot of this functionality, albeit in different ways. My design goal is more of what I try *not* to do -- specifically, *not* preclude the user from doing what he wants. [Or, in the case of Mail.App, what characters he may have in his Subject line...] >Having little pictures of the sender doesn't really help ME all that >much; I either already know what the person looks like who works in my >organization or they are strangers and don't have any "faces" online. >Is that *really* an aid to productivity? How about this "lip server" >that I mentioned in a previous message? It's pretty spiffy, but >before including that in an application, there are many more critical >feature that I need, like the file inclusion capability. > >The Mail application is cute and usable for a great many folks. But >is it definately *not* a heavy duty tool usable for some of us that >deal with large volumes of mail daily as a routing part of our work. You can damn Mail.app on a lot more than its excessive cutesiness. In 1.0, there are some serious security bugs in it. NeXT supposedly fixed the ones I reported in 2.0, but in a very kludgy manner (you really don't want to know...). Let's face it, Mail.app is a toy mailer for demonstrations. Traditional tools (e.g. mh, mm, /usr/ucb/Mail, elm, etc.) and their modern equivalents (in a sense, MailManager is a graphical MM) are heavy-duty mailers for seriosu use. _____ | ____ ___|___ /__ Mark ("Gaijin") Crispin "Gaijin! Gaijin!" _|_|_ -|- || __|__ / / R90/6 pilot, DoD #0105 "Gaijin ha doko?" |_|_|_| |\-++- |===| / / Atheist & Proud "Niichan ha gaijin." --|-- /| |||| |___| /\ (206) 842-2385/543-5762 "Chigau. Omae ha gaijin." /|\ | |/\| _______ / \ FAX: (206) 543-3909 "Iie, boku ha nihonjin." / | \ | |__| / \ / \MRC@CAC.Washington.EDU "Souka. Yappari gaijin!" Hee, dakedo UNIX nanka wo tsukatte, umaku ikanaku temo shiranai yo.
pbiron@weber.ucsd.edu (Paul Biron) (12/05/90)
In article <1990Dec4.045426.28457@ni.umd.edu> louie@sayshell.umd.edu (Louis A. Mamakos) writes: >In article <130125@gore.com> jacob@gore.com (Jacob Gore) writes: >>2. It annoys me that everybody, including NeXT, is going out of their way to >>improve the appearance of electronic communications, while sacrificing >>user's editing habits. I've been bitching about being unable to use Emacs >>to create messages ever since I started using the machine, in 0.8 days. >>Result from NeXT: none. Result from me: I don't use NeXT Mail. I have >>MMDF installed instead of sendmail, and I use msg to read and write mail. >>Msg respects users' preferences for various editors, while Mail sticks you >>with the Text object. > While I agree with both of you (except for me, it's vi instead of emacs that I want), I just wanted to make sure you were both aware of the KeyBindings default of Mail.app. From the online help for Mail.app (7.1, on Defaults): KeyBindings Emacs-style key bindings in the Send window This is a binary (YES/NO) default, which is NO by...default:-) Paul Biron pbiron@ucsd.edu (619) 534-5758 Central University Library, Mail Code C-075-R Social Sciences DataBase Project University of California, San Diego, La Jolla, Ca. 92093
mpf@triplea.cs.umd.edu (Martin Farach) (12/05/90)
In article <4164@network.ucsd.edu> pbiron@weber.ucsd.edu (Paul Biron) writes: >In article <130125@gore.com> jacob@gore.com (Jacob Gore) writes: >>2. It annoys me that everybody, including NeXT, is going out of their way to >>improve the appearance of electronic communications, while sacrificing >>user's editing habits. I've been bitching about being unable to use Emacs >>to create messages ever since I started using the machine, in 0.8 days. >>Result from NeXT: none. Result from me: I don't use NeXT Mail. I have >>MMDF installed instead of sendmail, and I use msg to read and write mail. >>Msg respects users' preferences for various editors, while Mail sticks you >>with the Text object. > While I agree with both of you (except for me, it's vi instead of emacs that I want), I just wanted to make sure you were both aware of the KeyBindings default of Mail.app. From the online help for Mail.app (7.1, on Defaults): KeyBindings Emacs-style key bindings in the Send window The key point is that there is a lot more to Emacs than key bindings. There are all kinds of custimizations that can be done that really improve emacs and all kinds of functions without key bindings that I use on a regular basis. Therefore, even if under 2.0, the editor has "emacs-like" bindings, that doesn't make it Emacs. Martin Farach -- -- Martin Farach mpf@cs.umd.edu University of Maryland Department of Computer Science College Park, Maryland 20742
glenn@heaven.woodside.ca.us (Glenn Reid) (12/07/90)
You guys have been bashing Mail.app a lot, and I have to come to its defense. I've used MH extensively. I've used "mhe". I've used /usr/ucb/Mail. I've used Sun's Mailtool under SunView. They all sort of work, and they all have serious limitations. I'm also an emacs weenie, for what it's worth. In article <12305@milton.u.washington.edu> mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) writes: >Let's face it, Mail.app is a toy mailer for demonstrations. >Traditional tools (e.g. mh, mm, /usr/ucb/Mail, elm, etc.) and their >modern equivalents (in a sense, MailManager is a graphical MM) are >heavy-duty mailers for seriosu use. I don't agree with you, and I also think you must be joking by putting /usr/ucb/Mail in this list. I'd like to know what you think of as "heavy duty" or "serious use". What I think you really mean is "what I'm used to" or perhaps "what I require by feeling the need to read my mail from eighteen different computers at various times of the day." I use and like Mail.app, and I process hundreds of messages a day. It's a lot more than a toy, and it does a lot of things quite well. While I'm at it, I tried your MailManager app and found that it had one of the worst interfaces I've used in quite some time, didn't dovetail at all well with Mail.app, and I forget what else, because I deleted it. Anyway, why don't we each promote our own tools, if we must, without having to bash the other ones. Some people actually *like* Edit and Mail.app and the other NeXT tools. You're free to improve upon them, or do something different, but they work fine, are robust and far more than "toys". Glenn P.S. I'm sure you're amused by all the Japanese in your .signature line, but I'm not, and I think it's a waste of bandwidth. -- Glenn Reid RightBrain Software glenn@heaven.woodside.ca.us PostScript/NeXT developers ..{adobe,next}!heaven!glenn 415-851-1785
mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) (12/09/90)
In article <356@heaven.woodside.ca.us> glenn@heaven.woodside.ca.us (Glenn Reid) writes: >You guys have been bashing Mail.app a lot . Major security holes (some fixed in 2.0, I haven't tested 2.0 yet). . Lack of basic features that even text-oriented mailers have. . Limitations on the To: field of messages. . Limitations on what may be in the Subject: field of messages. . The attitude that "all the world's a NeXT" (like "all the world's a VAX"), so there's no need to worry about non-NeXT users. . The attitude that "all the world's a tiny cluster of NeXT machines" so you have low-res bitmaps of everyone's picture. . A non-intuititive interface (how would you know that the way to attach a file is to go to the directory browser and drag its icon into the message? I'm still not sure how you insert a file). . Obscure buttons with pretty icons but no immediately obvious purpose. . No internal help to explain the interface or obscure buttons (it is unforgivable for an application not to have a help button for every menu and every major window). . No way (that I can tell) to display more than one message at a time. . No way (that I can tell) to have more than one mailbox open at a time. . By default, Mail.app steals the mail from /usr/spool/mail into its own Mailboxes directory, taking the messages away from other tools. . Mail.app's non-textual formats (NX_Attachments?) are not published in the RFC library, making it difficult to create compatible implementations for other architectures. . Mail.app's non-textual formats are completely different from the non-textual formats used in present Internet multimedia e-mail research. The world is moving towards open, common standards, not closed, proprietary ones. . Mail.app periodically clobbers its mailbox. [The victims of this bug are a great source of new MailManager users.] > I also think you must be joking by putting >/usr/ucb/Mail in this list. It is the single mail program that more Unix users use than any other program; particularly administrator and non-computer types. I never use it myself, but I have to acknowledge its overwhelming importance and the fact that any mailer that is incompatible from /usr/ucb/Mail cuts itself off from a large body of potential users. >What I think you really mean is "what >I'm used to" or perhaps "what I require by feeling the need to read my >mail from eighteen different computers at various times of the day." This sort of personal insult does not belong in a serious discussion. It so happens that some individuals, including me, have multiple mailboxes at two or three machines for the purpose of vectoring messages relevant to business at that machine. For example, it makes little sense to receive Unix patches on a DEC-20 (or vice versa). I rarely log in on other machines -- that's that IMAP was designed to solve. I use the graphical MailManager when logged in on the console of my NeXT, and the text-oriented MS when using a modem and a 24x80 terminal. Internally, both programs use the same mail-access library. >While I'm at it, I tried your MailManager app and found that it had >one of the worst interfaces I've used in quite some time, didn't >dovetail at all well with Mail.app, and I forget what else, because I >deleted it. You are entitled to your opinion. A growing community of MailManager users have the opposite opinion. One man's meat may be another man's poison. But, as noted above, there's a lot more to bash Mail.app on that merely user interface issues. Some of my most enthusiastic users are former Mail.app users who found that Mail.app was unusable and who find MailManager's interface to be a great improvement. Some are "computer weenies", others are computer novices, e.g. a faculty member who was pushed into using Mail.app by a local NeXT-junkie and gave up on it in favor of MailManager within a week. It was a non-goal of MailManager to dovetail with Mail.app -- the goal was to dovetail with other Unix mail tools. It is Mail.app that fails to dovetail with anything else. _____ | ____ ___|___ /__ Mark ("Gaijin") Crispin "Gaijin! Gaijin!" _|_|_ -|- || __|__ / / R90/6 pilot, DoD #0105 "Gaijin ha doko?" |_|_|_| |\-++- |===| / / Atheist & Proud "Niichan ha gaijin." --|-- /| |||| |___| /\ (206) 842-2385/543-5762 "Chigau. Omae ha gaijin." /|\ | |/\| _______ / \ FAX: (206) 543-3909 "Iie, boku ha nihonjin." / | \ | |__| / \ / \MRC@CAC.Washington.EDU "Souka. Yappari gaijin!" Hee, dakedo UNIX nanka wo tsukatte, umaku ikanaku temo shiranai yo.
jacob@gore.com (Jacob Gore) (12/09/90)
/ comp.sys.next / glenn@heaven.woodside.ca.us (Glenn Reid) / Dec 6, 1990 / > Some people actually *like* Edit and > Mail.app and the other NeXT tools. You're free to improve upon them, > or do something different, but they work fine, are robust and far more > than "toys". Unfortunately, since their sources are not available, improving upon them means first doing them from scratch. It's easier for people with the sources to do an incremental change than it is for us to duplicate their work and then improve it. So, we complain to them. Jacob -- Jacob Gore Jacob@Gore.Com boulder!gore!jacob
cnh5730@calvin.tamu.edu (Chuck Herrick) (12/10/90)
In article <12613@milton.u.washington.edu) mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) writes:
). Major security holes (some fixed in 2.0, I haven't tested 2.0 yet).
it is customarily in good taste to reserve comment until you know
about what you speak.
). Lack of basic features that even text-oriented mailers have.
yeah, like voice-embedded mail?
). Limitations on the To: field of messages.
). Limitations on what may be in the Subject: field of messages.
big deal. just because it doesn't do what your Mail-app does.
). The attitude that "all the world's a NeXT" (like "all the world's a
) VAX"), so there's no need to worry about non-NeXT users.
). The attitude that "all the world's a tiny cluster of NeXT machines"
) so you have low-res bitmaps of everyone's picture.
NeXT has raised the lowest common denominator of computing. VAX did
this at one time and then died of cardiovascular congestion. You can't
raise the lowest common denominator of computing and not carve new
ground.
). A non-intuititive interface (how would you know that the way to
) attach a file is to go to the directory browser and drag its icon
) into the message? I'm still not sure how you insert a file).
read the damn manual
). Obscure buttons with pretty icons but no immediately obvious
) purpose.
). No internal help to explain the interface or obscure buttons (it is
) unforgivable for an application not to have a help button for every
) menu and every major window).
oh dear, it's a matter of personal taste after all, isn't it
). No way (that I can tell) to display more than one message at a time.
). No way (that I can tell) to have more than one mailbox open at a
) time.
jeepers, I just can't recall your post asking how to do this.
). By default, Mail.app steals the mail from /usr/spool/mail into its
) own Mailboxes directory, taking the messages away from other tools.
). Mail.app's non-textual formats (NX_Attachments?) are not published
) in the RFC library, making it difficult to create compatible
) implementations for other architectures.
go to developers camp
). Mail.app's non-textual formats are completely different from the
) non-textual formats used in present Internet multimedia e-mail
) research. The world is moving towards open, common standards, not
) closed, proprietary ones.
so I have to be subjugated by your standards? like X-windows?
can you say No.
). Mail.app periodically clobbers its mailbox. [The victims of this
) bug are a great source of new MailManager users.]
I, for one, have never had this happen.
But now we get down to the kernel of the issue. Little Markie has his
own Mail-app he'd like us all to use, and we're just not getting the
message, are we?
)/usr/ucb/Mail
)It is the single mail program that more Unix users use than any other
)program; particularly administrator and non-computer types.
open Terminal and type /usr/ucb/Mail. or /usr/ucb/mail. feel better?
)It was a non-goal of MailManager to dovetail with Mail.app -- the goal
)was to dovetail with other Unix mail tools. It is Mail.app that fails
)to dovetail with anything else.
Try
verbose == offglenn@heaven.woodside.ca.us (Glenn Reid) (12/18/90)
In article <12613@milton.u.washington.edu> mrc (Mark Crispin) writes: [ lots of objections to Mail.app deleted, along with parts of previous discussion about why Mail.app is a "toy" and should not be used ] >> I also think you must be joking by putting >>/usr/ucb/Mail in this list. >It is the single mail program that more Unix users use than any other >program; particularly administrator and non-computer types. I never >use it myself, but I have to acknowledge its overwhelming importance >and the fact that any mailer that is incompatible from /usr/ucb/Mail >cuts itself off from a large body of potential users. The NeXT mailer is much more compatible with /usr/ucb/Mail than MH, for instance, which puts each message in a separate file and loses the "From " line from the beginning. The NeXT mail files are stored in folders in exactly the same file format as /usr/spool/mail, and you can read it *directly* with /usr/ucb/Mail -f ~/Mailboxes/Active.mbox/mbox if you want to (although it may require rebuilding Mail.app's index file). It's hard to get more compatible than that. Also, in 2.0, you can specify custom mail spool files and custom mailers (thanks, Bryan!) so you can put arbitrary filters between your /usr/spool/mail/ mailbox and the Mail.app if you want to. >>What I think you really mean is "what >>I'm used to" or perhaps "what I require by feeling the need to read my >>mail from eighteen different computers at various times of the day." > >This sort of personal insult does not belong in a serious discussion. It isn't a serious discussion; that's the point. It was a soliloquy until I decided to flame you for blasting Mail.app in what I thought was a pretty self-serving way. You have awfully strong things to say, and although some of your criticisms have merit, many are gratuitous and lead me to believe that it is more a religious issue for you than it is a rational discussion of tools. If you were a random mail user instead of the author of a competitive piece of software I might cut you a little more slack. >>While I'm at it, I tried your MailManager app and found that it had >>one of the worst interfaces I've used in quite some time, didn't >>dovetail at all well with Mail.app, and I forget what else, because I >>deleted it. > >You are entitled to your opinion. A growing community of MailManager >users have the opposite opinion. One man's meat may be another man's >poison. But, as noted above, there's a lot more to bash Mail.app on >that merely user interface issues. My whole point is that *no one is bashing MailManager*, but you feel the need to bash Mail.app. My point was "Mark, quit bashing Mail.app", not an attempt to get into an argument with you. I don't want to start bashing MailManager, I just want you to quit bashing other software because there's no point in it. If people want to use MailManager, that's great. >Some of my most enthusiastic users are former Mail.app users who found >that Mail.app was unusable and who find MailManager's interface to be >a great improvement. I'm glad people are using your software. I'm sure it has merit in many environments. However, the people who choose to use Mail.app instead of MailManager don't post long lists of what is wrong with MailManager to the net, although perhaps they'll start :-) >It was a non-goal of MailManager to dovetail with Mail.app -- the goal >was to dovetail with other Unix mail tools. That's brilliant. "Hey, let's take this really neat new computer and write a brand new mail tool for it that's completely incompatible with the one that ships with the machine! That way we can pretend it's not really a NeXT computer." > It is Mail.app that fails >to dovetail with anything else. That's not true. It uses the default /usr/ucb/Mail mailbox format to store its mail files. Very compatible. It sends mail with /usr/lib/sendmail. It works to/from many UNIX mail systems without modification, and the 2.0 version is even better about its compatibility. It doesn't support X.400 yet, but it seems to be a goal for NeXT. There are some gotchas, but no more than any other mail program I've used. Anyway, this is a silly discussion, and I will quit. I just wanted you to realize that I was flaming you, not MailManager, and I was defending Mail.app not entirely on its own merits, but in the sense of a public defender, since you were flaming software that wasn't likely to flame you back. Glenn -- Glenn Reid RightBrain Software glenn@heaven.woodside.ca.us PostScript/NeXT developers ..{adobe,next}!heaven!glenn 415-851-1785
vssarva@pollux.usc.edu (Venkata S. Sarva) (01/06/91)
Hello, Is there any public domain kermit for nextstation? Or can somebody help me with how to set up a modem to NextStation? What do I have to do if I want to use tip? Please reply to vsarva@nunki.usc.edu Thanks Venkata Sarva ( vsarva@nunki.usc.edu )