[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: What I see as problems to solve ... and a strawman solution



On Feb 1, 2004, at 1:49 PM, Paul Smith wrote:


At 18:58 01/02/2004, Chuq Von Rospach wrote:
No, but the point is, XML is a way to distribute that information in a way that is unambiguous (you can't mistake a header for a body, you can't mistake a subject line with a from line

Assuming it's well formed XML.. Oh, the same can be said about RFC822 headers..

If it's not, you reject it, and should. And I think the standards should make that explicit, since the e-mail is littered with problems caused by us building systems that tolerate "legacy issues" in an attempt to do the "right" thing. if we're starting over, let's not let sloppy coding enter the system in the first place this time.

and processing those headers. Plus, there are zillions of tools that can be used to generate, read and process XML

Lots can read DBF files - why not use those?

shrug. because it assumes a storage model, and I think we should avoid that. dbf files weren't intended to be a cross-platform network delivery interface, XML was. You're actually better off stuffing it in a MySQL MyISAM table, because that's built for binary compatibility. But even that assumes that the filestore on the far side is compatible with the filestore on this side, and I don't want to assume that. XML doesn't.

I could write a complex XML parser, or I could write a simple line based parser. I know which I'd prefer..

But what's more important, building a system that functions well, or is easy to program? Sorry, but this is a strawman. And it's one of the reasons we're in the situation we are today. Let's not re-impelment sloppy data methods becaue it's less work.

Yes, RFC822 headers are a bit of a mess, that doesn't mean that a new line based protocol would have to be:

Subject: This is my nice subject\nwith some line breaks in it
From: myname@xxxxxxxxxxx, My Name
To: "Bill@xxxxxxxxxxxxx", "Bill Gates"
To: "elvis@xxxxxxxxxxx", "Elvis \"the king\" Presley"

As someone who writes stuff that deals with this for a living, "bit of a mess" is like saying it's "kinda dead".

To name just one instance where line-based protocols suck and XML would make everyone's life easier:

Subject: Re: [mail-ng] This is a subject line

Now, parse that out rationally and display it properly in Swedish. Or Japanese. or French.

If, instead, it's packaged up in XML:

	<subject>This is a subject line</subject>
	<subject_reply>Yes</subject_reply>
	<subject_tag>mail-ng</subject_tag>

it's trivial to localize that to any language. Plus, an MUA can be trivially configured to re-arrange the information pieces. If you are, for instance, someone who doesn't like/want mailing list tags in your subject line, it's now trivial and unambiguous to TURN THEM OFF, meaning there's now no reason not to include them and leave them up to the user to show or hide -- ending *that* religious fight forever.

So you end up with:

[swedish for Subject] SV: This is a subject line

(and yes, I've gone blank on what the "subject" is in swedish. ohwell).

to see why XML is useful, stop thinking that we're going to make a 1:1 translation of line-based info to XML, and start thinking in terms of the meta-data that is attached to a message. Subject itself has multiple pieces of meta-data wedged in it. Split that meta data out into unambiguous pieces, and give the end-user control of which parts to display and how to display it. In fact, now that I think of it, subject_tag is probably unnecessary, because the meta-data will likely have info on the mailing list embedded in it (the ng of the list-id and list-* RFCs) and the subject tag would be generated off of that -- if the user wanted it.

And then someone sends something you'd not seen before and trashes it.

like we don't do that today? At least this way, we have a structure we don't have to guess at. it's either well-formed and standards conforming or it's not. and if it's not, that's not the receiver's fault.

Don't assume that everything has the power of a modern mobile phone. Simple mailing needs to be possible with a minimum of complexity - that's one of the reasons SMTP became popular when other systems didn't.

so you argue that we should gut email to the lowest possible level of capability? Sorry, I don't buy that. It's not the 70's any more. let's not try to take mail-ng back there -- because it'll be rejected in the market if you try.

Besides, globally, that lowest-demoninator aspect of email has already been handed over to SMS, just as the immediacy aspect of e-mail has been handed to IM. there's no need to support that kind of simple e-mail, because it's already moved to a different protocol, one that SMTP interfaces to, and one which the ng system will want to gateway to as well.