attaching or inlining? what to do when you're stuck with a stupid mail client???[Ay
Geoff Thorpe
geoff at geoffthorpe.net
Tue Oct 14 08:26:53 CDT 2003
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/
More information about the wine-devel
mailing list