Hello Thomas,
Sunday, December 28, 2003, 10:04:34 PM, you wrote:
>> The Bat is very best at representing a lot of details from all the
>> delivery process. So it's easy to second-check if mail was from a
>> spammer, or a commercial source, or your friend. The received mail
>> has full information. Surely it is a bug if the sent mail is lacking
>> full information!
TF> It isn't. The "sent" time will still be in the Received headers at
TF> recipient's side.
Quite so.
TF> As MAU has pointed out, the "created" time must be
TF> shown in the headers, according to RFCs.
I will defer to you guys about this.
>> The Sent folder has Two date fields: Saved, and Created. This Created
>> field should be listing the date and time when messages are sent. As
>> it stands, these fields are redundant meaning-wise. And they have the
>> same contents. A Saved date would make more sense for a text editor. A
>> Mailer should preserve the time mail was mailed. :-)
TF> I agree with you half-way here. The fields are redundant, and I would
TF> like to have the fields "created" and "sent". The latter would just be
TF> TB internal and would show me when the mail was actually sent, and as
TF> it is not an RFC header that would go with the message. But it would
TF> be helpful on sender's side.
Perhaps the transmission process does not need to be told the time
when a message is sent; but instead it provides this information
itself.
So the need for this fact is not there. But a need suggested by a
means of transmission seems hardly a demand against what type of fields
data should be able to be filed under.
>> It is surely a bug to mislead the user.
TF> It's a feature request you have.
I hadn't really thought about it much.
>>>From URL:
>>> An error or defect in software or hardware that causes a program to malfunction.
>> This definition of bug is too concise.
TF> You are not in software engineering, are you?
Nope. But do standards dictate external appearance, menu displays,
keys to advance to new mail or other content?
Miguel cited an RFC. So to suggest that you really need to be abiding
certain rules in the storage of a message that should be sent out on
the internet later. But then, that is about what you need to consider
to have effective transmission once these electrons have taken flight
in other formations.
The same RFC said:
Some message systems may store messages in formats that
differ from the one specified in this standard. This specifica-
tion is intended strictly as a definition of what message content
format is to be passed BETWEEN hosts.
So, prior to its sending, I guess in an Outbox it could be in any
form. Not really. But, the main goal when you have a program handling
content is how to effectively manipulate the content, and display it
in a readable form. I guess the headers would be in the sense of the
complete e-mail source. I know some programs definitely seem to vary
from an ordinary message source display in a Sent folder. Have you
used Pegasus Mail? I think there are a few headers it doesn't bother
to represent.
But in general, you have internal data, and external representation.
Items in the Sent folder can be flagged, read, unread, coloured black
and blue. Would it be a bug or not a bug if a sent message could not be
coloured?
Or they could be Read, but not Unread again?
The subject of this thread isn't much of an example for where you
define what is a bug. I mean, mainly where you talk about something
malfunctioning, is where you may have a lot of chaos. A lot of users
complain. Effective work cannot be done. Or something thereabouts.
Not so much at some periphery of operation where data conveys some
impression most of the time which is very effective, and few
surprises. I can't really rate it on a scale of 1 to 10. But if you
can't trust a sort on a main aspect of content that may occur to you,
it seems annoying. TB shines at the sort.
Sorry, some of my comments might be a bit redundant.
--
Best regards,
Adam
________________________________________________
Current version is 2.02.3 CE | "Using TBUDL" information:
http://www.silverstones.com/thebat/TBUDLInfo.html
