attaching or inlining? what to do when you're stuck with a stupid mail client???[Ay

[Geoff Thorpe]

On October 10, 2003 01:48 pm, Alexandre Julliard wrote:
> Geoff Thorpe <geoff at geoffthorpe.net> writes:
> > But if mailman can't do it, there would still be other ways to
> > organise this, only they would be uglier and trickier. Do we actually
> > know yet if someone at winehq will "let this happen"? And likewise,
> > would Alexandre (as the primary target of wine-patches) like to
> > express any thoughts on this? :-)
>
> Personally I'd love to have a filter to make things more uniform,
> assuming it's robust enough to not cause more trouble than it
> solves. But I have no idea what's involved to set this up on the mail
> server so I'm not the one who can make it happen.
>
> For the format, I guess using a text/plain attachment (without any
> quoted-unreadable crap of course) would be better since it's easier to
> process on the user side; as long as the format is standardized it
> should be easy to turn the attachment back to inline form, but doing
> it the other way is harder.

I'm in[c]lined to agree :-)

I assume the filter script could also be used client-side for those who 
wish to have the mails formatted differently. As you say 
attached->inlined is easier than inlined->attached, which raises the 
question as to what can be done when posts already have patches inlined. 
Probably nothing I guess. Shachar - what do you think?

> Multiple patches in the same email are of
> course a very bad idea, I'm not sure why you insist on being able to
> do that, and I certainly don't see any reason to make the filter
> support them.

I'm not insisting on anything, just arguing against puritanism. I don't 
want to debate whether it's a good idea or not, and indeed I don't want 
my opinion (whatever it might be) to unduly influence the choices made. I 
think the filter should, however, process the widest category of inputs 
possible with the cleanest/most-standardised output(s) possible. 
Everything the filter doesn't handle needs to be passed through as is 
(requiring flags or prepended-text to alert readers that it wasn't 
processed) or bit-bucketed. Bouncing is IMHO not something a mail list 
should do, for the spam/virus reasons I mentioned a couple of posts ago. 
As for what you recommend people send to the list, and what you or anyone 
else accepts, that's a different issue. But "wide-tolerance/thin-output" 
makes sense for the mail-processing pipeline, whatever the policies 
outside that might be.

Cheers,
Geoff

-- 
Geoff Thorpe
geoff at geoffthorpe.net
http://www.geoffthorpe.net/