zymail-devel Mailing List for Zymail
Brought to you by:
jstrout
Menu
▾
▴
zymail-devel — Discussion for the developers of Zymail
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(332) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
(29) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Thom M. <li...@th...> - 2008-07-05 16:18:32
|
We had a good blitzkrieg of initial development, then other priorities got the best of everybody. Now that I'm working for REAL, after spending eight hours a day on the computer I usually find myself spending my free time *not* programming. I'm planning on releasing the sidebar code I created to the general public. So far, both that and my AnimationKit are products of the time I spent working on the Zymail UI. On Jul 5, 2008, at 11:07 AM, Robert Lobsinger wrote: > Good to hear. It's fascinating to watch from the sidelines. Maybe > someday I'll get smart enough to actually participate. -- Thom McGrath IT Developer REAL Software, Inc. (512) 328-7325 x725 (512) 328-7372 <http://www.realsoftware.com/> |
|
From: Robert L. <rob...@hu...> - 2008-07-05 15:07:50
|
> >> is this project cancelled? > > No, it's just dormant. But I suspect it will shake itself to life > again at some point. Good to hear. It's fascinating to watch from the sidelines. Maybe someday I'll get smart enough to actually participate. -Robert |
|
From: Joe S. <jo...@in...> - 2008-07-05 04:02:08
|
On Jul 3, 2008, at 4:40 PM, Sascha Schneppmueller wrote: > is this project cancelled? No, it's just dormant. But I suspect it will shake itself to life again at some point. Best, - Joe -- Joe Strout Inspiring Applications, Inc. http://www.InspiringApps.com |
|
From: Sascha S. <sch...@gm...> - 2008-07-03 22:40:43
|
Hello, is this project cancelled? Regards Schneppi -- Bob Hope - "Middle age is when your age starts to show around your middle." |
|
From: <jo...@in...> - 2008-01-28 05:04:28
|
We can now move all selected messages to any folder using the "Move" submenu â or as a shortcut, you can press Backspace or Delete to move the selected messages to the Trash. Notifications all seem to be working properly; it's fun to have two Viewer windows open, with one showing the Trash folder, so that when you delete messages from the other one you immediately see them disappear from there and appear in the Trash. This means that Zymail should be actually usable, in at least a minimal way. I may spend a little more time checking import/export functions, to make sure I can safely back up my email in some standard format (probably Unix mbox), but once that's done I may switch over for either my work or personal account. (Probably the work one â the personal one gets so much spam that I will probably have to hook up the spam filter before using Zymail on that. Fortunately I already have a good spam filter from the now-defunct VerEx project.) Cheers, â Joe |
|
From: Joe S. <jo...@in...> - 2008-01-18 13:44:34
|
On Jan 17, 2008, at 11:22 PM, Steve Garman wrote: > Just doing a quick mail check before setting off for work, so I > haven't > checked properly but I suspect you may not have checked in > MoveCommand.rbbas Oops, quite right. Should be fixed now. Thanks, - Joe -- Joe Strout Inspiring Applications, Inc. http://www.InspiringApps.com |
|
From: Steve G. <zy...@sg...> - 2008-01-18 06:22:31
|
In a message regarding [Zymail-devel] Made a start on moving messages around dated Thu, 17 Jan 2008 21:04:27 -0700, jo...@in... = said that ... > I've added a MoveCommand, which is fired off by a Move To menu as = in Just doing a quick mail check before setting off for work, so I haven't checked properly but I suspect you may not have checked in = MoveCommand.rbbas -- Steve Garman Using RB2007r5 Professional on Windows Vista Ultimate |
|
From: <jo...@in...> - 2008-01-18 04:04:46
|
I've added a MoveCommand, which is fired off by a Move To menu as in Apple Mail. This calls a new MoveMessage command on StorageInterface. However, I've run out of time for today, and OnDiskStorage needs an implementation of this MoveMessage method... any volunteers, Bill? :) Once that's working, we'll put in some niceties (like keystrokes to move the selected message to the trash, advance to the next message, etc.), and Zymail will be darn close to livable. Cheers, â Joe P.S. Oh yes, I had to make one other change, this one to the way messages are sent out. The SMTP connection is now made to port 587 instead of 25, because Comcast without warning decided to block all outgoing connections to port 25. Cost me half a day, thinking it was something I'd screwed up when I installed a new machine on our network, and then working my way up the Comcast food chain to somebody who actually had a clue what was going on. Not a happy camper, I. Anyway, the port is currently hard-coded, but sooner or later we'll get a nice UI for defining SMTP servers, and then you can set it however you need. |
|
From: Bill J. <bi...@ge...> - 2008-01-12 04:25:43
|
On 11-Jan-08, at 1:00 PM, jo...@in... wrote: > I also added basic reply functionality. In fact, > I'm using it now. :) Cool, I like this header from your reply. X-Mailer: Zymail 0.0 (built 2008-01-11) bill |
|
From: <jo...@in...> - 2008-01-11 21:00:34
|
At Jan 11, 2008, at 1:43 PM, jo...@in... wrotre: > However, we're still having two bits of weirdness that appear to be in > OnDiskStorage... OK, actually only one of these was in OnDiskStorage; the other problem was elsewhere (I was failing to assign a unique ID to the newly created message). Both problems are now fixed. While I was at it, I also added basic reply functionality. In fact, I'm using it now. :) So to summarize, for those following along at home: you can now use Zymail to read your mail, and it will store it and only fetch the new stuff; and send mail (either new or a reply), and it'll be sent exactly once, and be stored in your outbox. Just remember that to get the queued mail to actually go out, you still need to use the "Send Queued Mail" command. I expect to fix that soon. Cheers, - Joe |
|
From: <jo...@in...> - 2008-01-11 15:56:30
|
Great work, Bill! I've checked in revision 38, which uses the new UpdateMessage method of StorageInterface to make sure that those status changes (Sent or Error) on outgoing messages are stored. I also implemented a change notice when a new message is put into the outbox, so the display gets updated properly. However, we're still having two bits of weirdness that appear to be in OnDiskStorage: 1. Whenever I add a new message to the outbox, it blows away the previous message, so that I never get more than one message here. I should instead have all messages ever stored in that box. The calling code is just: // Store it in the outbox Dim storage As StorageInterface = Factories.Storage Dim outbox As Mailbox = storage.GetMailboxes.Outbox storage.StoreMessage msg, outbox ..which seems simple enough to me. Why is this screwing up the previous contents of the mailbox? 2. The "Date Received" for all messages on my Inbox seems to be whenever I happened to switch to that box. It'll read 8:50 the first time; if I switch to Outbox and then switch back to Inbox a minute later, it claims everything was received at 8:51. Somehow the real date/time the messages were received is either not being stored, or not being retrieved. Anybody want to dig into these issues? Thanks, - Joe (Sent with Zymail!) |
|
From: Bill J. <bi...@ge...> - 2008-01-11 08:00:36
|
Joe Strout said > Not to seem over-eager here, but: how's it going? I'm pretty > excited about the new code and eager to make further progress on > Zymail, but it doesn't make much sense to add (for example) transfer > functions, which will also affect storage, while you're in the > middle of refactoring the current storage code. I've eliminated the ODS module and moved its methods into the OnDiskStorage class. Wrote a method called MoveMessages and couple supporting methods but haven't tested them in any way shape or form because I just wanted to get this out tonight. Bills-MacBook:~ billj$ svn status zymail M zymail/source/Zymail.rbvcp M zymail/source/MiscUtilities/Factories.rbbas M zymail/source/Storage/OnDiskStorage.rbbas bill |
|
From: Joe S. <jo...@in...> - 2008-01-08 23:23:03
|
On Jan 8, 2008, at 2:51 PM, Bill Johnson wrote: > Absolutely, it will be simple to do. Believe it or not I did this > already before Christmas but stopped just short of finishing. I looked > all over for that work but didn't find it. I went ahead and used the > odious err...I mean the ODS module instead. :) :) Thanks, your efforts are much appreciated! Best, - Joe -- Joe Strout Inspiring Applications, Inc. http://www.InspiringApps.com |
|
From: Bill J. <bi...@ge...> - 2008-01-08 21:51:12
|
On 8-Jan-08, at 7:22 AM, Joe Strout wrote: > Bill, can you take a stab at removing this ODS module, and rolling > its functionality back into the OnDiskStorage class? Anything we > need that's not part of StorageInterface must be added there; nothing > in the entire rest of the app should know anything about > OnDiskStorage's specifics. > Absolutely, it will be simple to do. Believe it or not I did this already before Christmas but stopped just short of finishing. I looked all over for that work but didn't find it. I went ahead and used the odious err...I mean the ODS module instead. :) bill |
|
From: Joe S. <jo...@in...> - 2008-01-08 15:22:17
|
On Jan 6, 2008, at 3:51 AM, Bill Johnson wrote: > Got an update to the OnDiskStorage class. Wrote this code about 3 > weeks ago. Just got around to integrating it. I see that you've added an ODS module, which adds extension methods to Mailbox and Message. This would be a good idea if we weren't trying to keep the storage implementation separate from the rest of the app. But since we are, it's a problem. Everything we need to do, storage-wise, needs to go through the StorageInterface. I realize that at the moment there is only one serious storage class, but there may be more someday, and switching from one to another should require nothing more than instantiating a different object in Factories.Storage. But currently, doing this would break the app (and probably corrupt your data) in all sorts of exciting ways, since any method using these extension methods would be writing to disk even if your storage object does something completely different. Bill, can you take a stab at removing this ODS module, and rolling its functionality back into the OnDiskStorage class? Anything we need that's not part of StorageInterface must be added there; nothing in the entire rest of the app should know anything about OnDiskStorage's specifics. Thanks, - Joe -- Joe Strout Inspiring Applications, Inc. http://www.InspiringApps.com |
|
From: Bill J. <bi...@ge...> - 2008-01-06 10:51:30
|
Happy new year all, Got an update to the OnDiskStorage class. Wrote this code about 3 =20 weeks ago. Just got around to integrating it. =95 Gave OnDiskStorage a Constructor where its DataFolder can be set. =20= This for the future case where an ODS instance can be used in =20 importing another Zymail DataFolder. Previously ODS automatically used =20= Documents.Child( "Zymail Data" ). =95 Gave the StorageInterface an UpdateMessage( msg As Message ) method. = =20 Implemented in both OnDiskStorage and NullStorage. =95 Caching Message objects in a WeakRef array. (Will most likely switch = =20 this to a dictionary) =95 Changed the folder structure in the data folder. It's best to delete = =20 your old Zymail Data folder before running this update. =95 Rewrote a lot of ODS' code--will add comments to its methods soon. Bills-MacBook:~ billj$ svn commit zymail -m 'changes to OnDiskStorage' Sending zymail/source/CustomControls/MailboxList.rbfrm Sending zymail/source/MiscUtilities/Factories.rbbas Sending zymail/source/Storage/NullStorage.rbbas Adding zymail/source/Storage/ODS.rbbas Sending zymail/source/Storage/OnDiskStorage.rbbas Sending zymail/source/Storage/StorageInterface.rbbas Sending zymail/source/Windows/ViewerWindow.rbfrm Sending zymail/source/Zymail.rbvcp Transmitting file data ........ Committed revision 34. bill |
|
From: Arnaud N. <ar...@tr...> - 2008-01-02 23:47:34
|
Le 2 janv. 08 =E0 21:17 soir, Joe Strout a =E9crit: >> But, maybe we shouldn't wrap and let the client app wrap where >> needed. > > For styled text, sure, but not for plain text. Some (admittedly > poorly-written but nonetheless common) MTAs will truncate or > otherwise abuse lines longer than 76 characters. Staying under 72 > characters is good practice for a MUA. See RFC 1521 for example: > <http://www.math-inf.uni-greifswald.de/~teumer/mime/1521/ > Appendix_B.html> Is that good for something to wrap text? I surely prefer unwrapped =20 paragraphs (easier to read) while I don't see a good point, in terms =20 of reading, to wrap. >> > True, and Zymail too should be prepared to soft-wrap long lines. > It's the standard practice of being a good citizen in a heterogenous > environment: (1) follow all standards as well as you can; and (2) be > prepared to deal with others who are not following the standards. I don't see the point to follow the standard if it's better otherwise =20= (the standard for real mails, really?).= |
|
From: Arnaud N. <ar...@tr...> - 2008-01-02 23:47:34
|
Le 2 janv. 08 =E0 22:22 soir, Joe Strout a =E9crit: >>> > "Not modify the sender's text outbound" here is deceptive. WE are > the sender. It's up to us -- the Zymail developers -- to send text > according to the standards. I can't believe it's the standards (at least, not the standard that =20 should be followed). Do you really love these wrapped characters? I certainly want my e-mails to stay formatted as I have sent them!= |
|
From: Tim J. <tj...@to...> - 2008-01-02 22:36:21
|
On Jan 2, 2008, at 2:22 PM, Joe Strout wrote: > On Jan 2, 2008, at 1:58 PM, Tim Jones wrote: > >> When Jason changed the mail list manager in 2006, we all started >> seeing our mails trnucated. It raised quite the dust storm and >> resulted in a few feature requests to return things to the pre-change >> settings where paragraphs/long test lines were wrapped by the mail >> client. The biggest issue was the wrapping of links. We all >> (apparently incorrectly) assumed this was something Jason/Mailman >> did. > > I still believe it was. > >> However, since your email from Zymail got through "unwrapped" - >> at least on my end - it appears that the change may have actually >> been in a Mac Mail update that occurred at the same time. > > I don't see how that follows at all. We have observed: > > 1. Mail sent to the RS list with many clients was unwrapped before > 2006. > 2. Mail sent to the RS list with many clients was overly wrapped > after 2006, and as I recall, Jason said that this was caused by a > change in the list manager. > 3. My unwrapped Zymail message, sent to a SourceForge list and NOT to > any RS list, came through unwrapped. Both RS and SourceForge use Mailman. RS has placed a wrapper on it, but I believe that Jason indicated it was still Mailman underneath. > I don't see how observation 3 has anything do do with observations 1 > and 2, and would allow us to conclude anything at all. Again, please > spell out how you reach this conclusion in simple steps. Since both use the same list manager, I would expect both to wrap the text. However, I've now done more tests and I retract my statement as mail sent to my ./Mac account from this account arrive unmolested and unwrapped. Therefore, Apple Mail client must not be the guilty party in the artificial wrap scandal. > Incidentally, your message (to which I am now replying) appears to > have hard line breaks in it, at least as viewed by Apple Mail. Mine > from Zymail, sent to the same list, does not. From THESE two > observations we can conclude that your client differs from Zymail's > current wrapping behavior, and that the SourceForge list doesn't hard- > wrap lines (which is as it should be; a well-behaved mailing list > will leave messages intact as much as possible, just as a well- > behaved text/plain email client will send its lines already > wrapped). But it still doesn't say anything about RS's mailing lists > or Apple Mail in particular. I've sent you an email from this same account off-list where I've unwrapped most of these paragraphs. is it wrapped when you receive it? > > It seems to me that to verify what you're claiming, we'd need to send > a clearly unwrapped message to one of RS's mailing lists and see how > it comes back. > >>> For styled text, sure, but not for plain text. Some (admittedly >>> poorly-written but nonetheless common) MTAs will truncate or >>> otherwise abuse lines longer than 76 characters. Staying under 72 >>> characters is good practice for a MUA. See RFC 1521 for example: >>> <http://www.math-inf.uni-greifswald.de/~teumer/mime/1521/ >>> Appendix_B.html> >>> >>> (Mind the line wrap!) >> >> The point exactly... > > Yes, but that is an issue only if a URL gets broken, and the > receiving client fails to put it back together. A sensible line-wrap > algorithm will not break a URL (note to self: check whether > StringUtils.WrapLines handles this), and a sensible client will > repair any URL surrounded in angle brackets anyway. My "Mind the > line wrap!" comment was meant to be ironic. > >> However, the line length definition as presented in 1522 states: >> >> " (4) Lines longer than 76 characters may be wrapped or truncated in >> some environments. Line wrapping and line truncation are STRONGLY >> DISCOURAGED, but unavoidable in some cases. Applications which >> require long lines must somehow differentiate between soft and hard >> line breaks. (A simple way to do this is to use the quoted-printable >> encoding.)" > > That's a description of how MTAs (Mail Transfer Agents, e.g. email > servers) should behave. We're writing a MUA (Mail User Agent), not > an MTA. Again, this just reemphasizes the general principle: every > agent should both follow standards as much as possible, and be > prepared to deal with other agents that fail to follow the standards. > > The standard for text/plain data is to wrap at 80 characters or less > (though 72 is safer, allowing several levels of quoted before you > have to get fancy). Though as noted earlier, we still need to look > at the later RFCs discussing format=flowed. > >> But, according to 1522, the creation should not artificially wrap >> text. > > No. 1521 states that mail *servers* should not artificially wrap > text they receive from mail clients. (And it points out that many > servers do so anyway, so to be safe, mail clients should anticipate > that). Re-read that Appendix B section: " There exist many widely-deployed non-conformant MTAs in the Internet. These MTAs, speaking the SMTP protocol, alter messages on the fly to take advantage of the internal data structure of the hosts they are implemented on, or are just plain broken. The following guidelines may be useful to anyone devising a data format (Content-Type) that will survive the widest range of networking technologies and known broken MTAs unscathed." That sounds to me like it is specifying the manner in which a MUA should prepare the content for transmission. And, from the last paragraph in Appendix B: " Please note that the above list is NOT a list of recommended practices for MTAs. RFC 821 MTAs are prohibited from altering the character of white space or wrapping long lines. These BAD and illegal practices are known to occur on established networks, and implementations should be robust in dealing with the bad effects they can cause." So getting back to the issue at REAL and their mail list implementation, I revert to the feature request submitted when the change occurred and retract my placing the blame on Apple Mail :-). The REAL server should not be modifying the mail as transmitted so long as it meets plain/text definitions. > >>> I didn't see that. Both your response and my original looked the >>> same to me. >> >> Did your original expand past the 72 character width for you? For >> me, it flowed to the width of my page (around 158 characters) while >> my reply wrapped everything - including your original. > > Yes, I see that too. > >> As for the other RFC's, I believe that they refer to handling >> received text, not sent text. I believe that we should not modify >> the sender's text outbound and allow teh recipients' mail client >> (Zymail or otherwise) decide what to do with the incoming data. > > "Not modify the sender's text outbound" here is deceptive. WE are > the sender. No we're not. The author of the email is the sender I was referring to. If I want hard returns, I'll place them. Otherwise, if I type my paragraph continuously (as in this one), I want it sent as I type it. Again, it's the receiver app's job to manage the display of the incoming data. > It's up to us -- the Zymail developers -- to send text > according to the standards. For regular old text/plain content, that > clearly means line breaks. It actually doesn't. "text/plain" only implies non-formatted text in concert with RFC 822, not that it must contain line breaks. > But I think the other RFCs need further > study. In a nutshell, I believe that if you set the Content-Type > correctly and use " \n" instead of just "\n" for your inserted > breaks, then savvy receiving clients will interpret those as soft > breaks and reflow them with the window width, while older clients > will still display the text properly wrapped. But, if we send the text content unmolested, the result is any MUA recipient will properly display the received data as determined by the local settings. The only thing that plain text should change is the removal of any type of non-ASCII formatting in compliance with RFC 822. Tim |
|
From: Joe S. <jo...@in...> - 2008-01-02 21:23:03
|
On Jan 2, 2008, at 1:58 PM, Tim Jones wrote: > When Jason changed the mail list manager in 2006, we all started > seeing our mails trnucated. It raised quite the dust storm and > resulted in a few feature requests to return things to the pre-change > settings where paragraphs/long test lines were wrapped by the mail > client. The biggest issue was the wrapping of links. We all > (apparently incorrectly) assumed this was something Jason/Mailman > did. I still believe it was. > However, since your email from Zymail got through "unwrapped" - > at least on my end - it appears that the change may have actually > been in a Mac Mail update that occurred at the same time. I don't see how that follows at all. We have observed: 1. Mail sent to the RS list with many clients was unwrapped before 2006. 2. Mail sent to the RS list with many clients was overly wrapped after 2006, and as I recall, Jason said that this was caused by a change in the list manager. 3. My unwrapped Zymail message, sent to a SourceForge list and NOT to any RS list, came through unwrapped. I don't see how observation 3 has anything do do with observations 1 and 2, and would allow us to conclude anything at all. Again, please spell out how you reach this conclusion in simple steps. Incidentally, your message (to which I am now replying) appears to have hard line breaks in it, at least as viewed by Apple Mail. Mine from Zymail, sent to the same list, does not. From THESE two observations we can conclude that your client differs from Zymail's current wrapping behavior, and that the SourceForge list doesn't hard- wrap lines (which is as it should be; a well-behaved mailing list will leave messages intact as much as possible, just as a well- behaved text/plain email client will send its lines already wrapped). But it still doesn't say anything about RS's mailing lists or Apple Mail in particular. It seems to me that to verify what you're claiming, we'd need to send a clearly unwrapped message to one of RS's mailing lists and see how it comes back. >> For styled text, sure, but not for plain text. Some (admittedly >> poorly-written but nonetheless common) MTAs will truncate or >> otherwise abuse lines longer than 76 characters. Staying under 72 >> characters is good practice for a MUA. See RFC 1521 for example: >> <http://www.math-inf.uni-greifswald.de/~teumer/mime/1521/ >> Appendix_B.html> >> >> (Mind the line wrap!) > > The point exactly... Yes, but that is an issue only if a URL gets broken, and the receiving client fails to put it back together. A sensible line-wrap algorithm will not break a URL (note to self: check whether StringUtils.WrapLines handles this), and a sensible client will repair any URL surrounded in angle brackets anyway. My "Mind the line wrap!" comment was meant to be ironic. > However, the line length definition as presented in 1522 states: > > " (4) Lines longer than 76 characters may be wrapped or truncated in > some environments. Line wrapping and line truncation are STRONGLY > DISCOURAGED, but unavoidable in some cases. Applications which > require long lines must somehow differentiate between soft and hard > line breaks. (A simple way to do this is to use the quoted-printable > encoding.)" That's a description of how MTAs (Mail Transfer Agents, e.g. email servers) should behave. We're writing a MUA (Mail User Agent), not an MTA. Again, this just reemphasizes the general principle: every agent should both follow standards as much as possible, and be prepared to deal with other agents that fail to follow the standards. The standard for text/plain data is to wrap at 80 characters or less (though 72 is safer, allowing several levels of quoted before you have to get fancy). Though as noted earlier, we still need to look at the later RFCs discussing format=flowed. > But, according to 1522, the creation should not artificially wrap > text. No. 1521 states that mail *servers* should not artificially wrap text they receive from mail clients. (And it points out that many servers do so anyway, so to be safe, mail clients should anticipate that). >> I didn't see that. Both your response and my original looked the >> same to me. > > Did your original expand past the 72 character width for you? For > me, it flowed to the width of my page (around 158 characters) while > my reply wrapped everything - including your original. Yes, I see that too. > As for the other RFC's, I believe that they refer to handling > received text, not sent text. I believe that we should not modify > the sender's text outbound and allow teh recipients' mail client > (Zymail or otherwise) decide what to do with the incoming data. "Not modify the sender's text outbound" here is deceptive. WE are the sender. It's up to us -- the Zymail developers -- to send text according to the standards. For regular old text/plain content, that clearly means line breaks. But I think the other RFCs need further study. In a nutshell, I believe that if you set the Content-Type correctly and use " \n" instead of just "\n" for your inserted breaks, then savvy receiving clients will interpret those as soft breaks and reflow them with the window width, while older clients will still display the text properly wrapped. Best, - Joe -- Joe Strout Inspiring Applications, Inc. http://www.InspiringApps.com |
|
From: Tim J. <tj...@to...> - 2008-01-02 21:08:31
|
On Jan 2, 2008, at 2:00 PM, Tim Jones wrote: >> However, the line length definition as presented in 1522 states: Also, everywhere I say 1522 I meant 1521. Busy day... Tim |
|
From: Tim J. <tj...@to...> - 2008-01-02 21:01:02
|
On Jan 2, 2008, at 1:58 PM, Tim Jones wrote: >> For styled text, sure, but not for plain text. Some (admittedly >> poorly-written but nonetheless common) MTAs will truncate or >> otherwise abuse lines longer than 76 characters. Staying under 72 >> characters is good practice for a MUA. See RFC 1521 for example: >> <http://www.math-inf.uni-greifswald.de/~teumer/mime/1521/ >> Appendix_B.html> >> >> (Mind the line wrap!) > > The point exactly... > > However, the line length definition as presented in 1522 states: > > " (4) Lines longer than 76 characters may be wrapped or truncated in > some environments. Line wrapping and line truncation are STRONGLY > DISCOURAGED, but unavoidable in some cases. Applications which > require long lines must somehow differentiate between soft and hard > line breaks. (A simple way to do this is to use the quoted-printable > encoding.)" BTW - that quote is from Appendix B -- General Guidelines for Sending Email Data Tim |
|
From: Tim J. <tj...@to...> - 2008-01-02 20:58:50
|
On Jan 2, 2008, at 1:17 PM, Joe Strout wrote: > On Jan 2, 2008, at 12:22 PM, Tim Jones wrote: > >> We all blamed the RS list mangler as the culprit when it appears that >> it was Mac Mail. > > I don't believe this argument yet. Please spell it out for me step > by step. When Jason changed the mail list manager in 2006, we all started seeing our mails trnucated. It raised quite the dust storm and resulted in a few feature requests to return things to the pre-change settings where paragraphs/long test lines were wrapped by the mail client. The biggest issue was the wrapping of links. We all (apparently incorrectly) assumed this was something Jason/Mailman did. However, since your email from Zymail got through "unwrapped" - at least on my end - it appears that the change may have actually been in a Mac Mail update that occurred at the same time. >>> But you have a point: we're not currently doing any line wrapping >>> when sending, and we probably should, at least for the plain-text >>> part (eventually we'll probably send both a plain-text part and an >>> HTML part for people who want to send styled email). Wrapping to 72 >>> characters is the standard. >> >> But, maybe we shouldn't wrap and let the client app wrap where >> needed. > > For styled text, sure, but not for plain text. Some (admittedly > poorly-written but nonetheless common) MTAs will truncate or > otherwise abuse lines longer than 76 characters. Staying under 72 > characters is good practice for a MUA. See RFC 1521 for example: > <http://www.math-inf.uni-greifswald.de/~teumer/mime/1521/ > Appendix_B.html> > > (Mind the line wrap!) The point exactly... However, the line length definition as presented in 1522 states: " (4) Lines longer than 76 characters may be wrapped or truncated in some environments. Line wrapping and line truncation are STRONGLY DISCOURAGED, but unavoidable in some cases. Applications which require long lines must somehow differentiate between soft and hard line breaks. (A simple way to do this is to use the quoted-printable encoding.)" Note the "STRONGLY DISCOURAGED" language - their emphasis, not mine. >> With the mail that you sent from ZyMail, the lines were not >> wrapped, so it read much more reasonably on my screen. > > What is "your screen"? What client did you use to read it? It's Mac Mail set to around 750 pixels wide. As a reference, the first wrap in the quoted text above is immediately following the word "DISCOURAGED". My point is that the receiving mail client should be responsible for "soft-wrapping" long text. >> On the other hand, this paragraph exceeds 72 characters and will be >> wrapped when you receive it. > > True, and Zymail too should be prepared to soft-wrap long lines. > It's the standard practice of being a good citizen in a heterogenous > environment: (1) follow all standards as well as you can; and (2) be > prepared to deal with others who are not following the standards. But, according to 1522, the creation should not artificially wrap text. This allows the recipient to decide how the text if formatted and presented. If I set my screen/display to wrap at 72 characters, then I expect the text to wrap. However, if the text was artificially wrapped on the outbound trip, my settings are irrelevant. >>>> Of course, this is sent from Mac Mail, so I expect your >>>> text to get butcher in the reply. >>> >>> No, looks fine to me. >> >> By butcher"ed", I meant that my response would have its lines wrapped >> while your original was unwrapped. > > I didn't see that. Both your response and my original looked the > same to me. Did your original expand past the 72 character width for you? For me, it flowed to the width of my page (around 158 characters) while my reply wrapped everything - including your original. As for the other RFC's, I believe that they refer to handling received text, not sent text. I believe that we should not modify the sender's text outbound and allow teh recipients' mail client (Zymail or otherwise) decide what to do with the incoming data. Tim |
|
From: Joe S. <jo...@in...> - 2008-01-02 20:27:27
|
On Jan 2, 2008, at 1:17 PM, Joe Strout wrote: >> But, maybe we shouldn't wrap and let the client app wrap where >> needed. > > For styled text, sure, but not for plain text. Some (admittedly > poorly-written but nonetheless common) MTAs will truncate or > otherwise abuse lines longer than 76 characters. This is a more complex subject than it first appears; there are different Content-Type modifiers (e.g. format=flowed) which affect how the data is to be interpreted. I believe RFCs 2464 & 3676 set the standard for this, but I haven't looked into them in much depth yet. Best, - Joe -- Joe Strout Inspiring Applications, Inc. http://www.InspiringApps.com |
|
From: Joe S. <jo...@in...> - 2008-01-02 20:17:38
|
On Jan 2, 2008, at 12:22 PM, Tim Jones wrote: > We all blamed the RS list mangler as the culprit when it appears that > it was Mac Mail. I don't believe this argument yet. Please spell it out for me step by step. >> But you have a point: we're not currently doing any line wrapping >> when sending, and we probably should, at least for the plain-text >> part (eventually we'll probably send both a plain-text part and an >> HTML part for people who want to send styled email). Wrapping to 72 >> characters is the standard. > > But, maybe we shouldn't wrap and let the client app wrap where > needed. For styled text, sure, but not for plain text. Some (admittedly poorly-written but nonetheless common) MTAs will truncate or otherwise abuse lines longer than 76 characters. Staying under 72 characters is good practice for a MUA. See RFC 1521 for example: <http://www.math-inf.uni-greifswald.de/~teumer/mime/1521/ Appendix_B.html> (Mind the line wrap!) > With the mail that you sent from ZyMail, the lines were not > wrapped, so it read much more reasonably on my screen. What is "your screen"? What client did you use to read it? > On the other hand, this paragraph exceeds 72 characters and will be > wrapped when you receive it. True, and Zymail too should be prepared to soft-wrap long lines. It's the standard practice of being a good citizen in a heterogenous environment: (1) follow all standards as well as you can; and (2) be prepared to deal with others who are not following the standards. >>> Of course, this is sent from Mac Mail, so I expect your >>> text to get butcher in the reply. >> >> No, looks fine to me. > > By butcher"ed", I meant that my response would have its lines wrapped > while your original was unwrapped. I didn't see that. Both your response and my original looked the same to me. Best, - Joe -- Joe Strout Inspiring Applications, Inc. http://www.InspiringApps.com |
