attaching or inlining? what to do when you're stuck with a stupid mail client???
Hi Dimi, I'm deeply sorry about that and I understand your frustrations for I have frustrations of my own using my mail client. The problem is that I have no other choice but to use Notes as a mail client for external emails at my company and Notes really screws up attachments and there's no way to configure it. Also, it wraps line longer than 70 characters, so inlining some of my patches will result in bogus patches. Then again, there's no way to configure it to disable line wrapping. And trust me, I've tried.... So what I'm gonna do in the future is inline patches that won't get line wrapped and attach the others the way I use too. Hopefully, most of them will be inlined. I apologize for the inconveniences. Dave "Dimitrie O. Paun" <dimi(a)intelliware.ca> on 10/08/2003 03:49:03 PM To: wine-devel(a)winehq.org cc: Dave Belanger/CSI(a)CSIDomain Subject: Re: patch for implementation of EMF driver SetPixel metarecord. On Wed, 8 Oct 2003 Dave_Belanger(a)cimmetry.com wrote: This patches are so hard to review. Not only are they not inlined, but they are attached as Application/OCTET-STREAM. This means I have to type about 8 keystrokes to open them in pine. Please, pretty please, try to inline them. If this doesn't wokr (have you tried?), at least attach them as text/plain. Thanks. -- Dimi. P.S. Inlining them is _far_ supperior to attachment. First, we can review them without any additional action. Second, we can simply press "Reply" and quote the code we want to comment on. This is very important.
On October 8, 2003 05:51 pm, Dave_Belanger(a)cimmetry.com wrote:
So what I'm gonna do in the future is inline patches that won't get line wrapped and attach the others the way I use too. Hopefully, most of them will be inlined.
Thanks Dave, This is very kind of you, but I think this is too much effort on your part. I've completely forgot you guys are using Notes (and 4 spaces tabs! :)), sorry about my winning (my wrists hurt from typing, and it's rather unpleasant to do all this useless typing, hope you understand). Anyway, maybe you can convince Notes to attach them as text/plain? If not, don't worry about it, I'll try deal with them... -- Dimi.
Dave_Belanger(a)cimmetry.com wrote:
Hi Dimi,
I'm deeply sorry about that and I understand your frustrations for I have frustrations of my own using my mail client.
The problem is that I have no other choice but to use Notes as a mail client for external emails at my company and Notes really screws up attachments and there's no way to configure it. Also, it wraps line longer than 70 characters, so inlining some of my patches will result in bogus patches. Then again, there's no way to configure it to disable line wrapping. And trust me, I've tried....
So what I'm gonna do in the future is inline patches that won't get line wrapped and attach the others the way I use too. Hopefully, most of them will be inlined.
I apologize for the inconveniences.
Dave
Can't you just call your diffs "something.txt" and attach them?
"Dimitrie O. Paun" <dimi(a)intelliware.ca> on 10/08/2003 03:49:03 PM
P.S. Inlining them is _far_ supperior to attachment. First, we can review them without any additional action. Second, we can simply press "Reply" and quote the code we want to comment on. This is very important.
Can't you do all of that with text/plain attachments? Don't you then get the added bonus that they do not line wrap, ever? Maybe we should put the "use .txt extension" into the FAQ. Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
As an alternative, if welcome on the list, we can zip/bzip the patch, this way they wont be mangled by Notes.
Can't you just call your diffs "something.txt" and attach them?
===== Sylvain Petreolle (spetreolle_at_users_dot_sourceforge_dot_net) ICQ #170597259 Say NO to software patents Dites NON aux brevets logiciels "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
On October 9, 2003 08:11 am, Sylvain Petreolle wrote:
As an alternative, if welcome on the list, we can zip/bzip the patch, this way they wont be mangled by Notes.
No, this is most definitely not welcome on the list... -- Dimi.
On October 9, 2003 08:46 am, Dimitrie O. Paun wrote:
On October 9, 2003 08:11 am, Sylvain Petreolle wrote:
As an alternative, if welcome on the list, we can zip/bzip the patch, this way they wont be mangled by Notes.
No, this is most definitely not welcome on the list...
Couldn't the wine-patches list server simply pull the emails apart and reconstruct them according to some simple rules? I'm no Perl hacker, but I'm sure this could be stitched together easily by someone who is. Eg. (a) prune out HTML emails, (b) prune out binary/executable attachments, and of course (c) identify common patch file-extensions/MIME-types/mistakes and correctly inline/attach them according to the preferred mechanics? This could be adapted and improved as/when new combinations of strange MUAs and strange users start to create difficulties - even Lotus Notes could be accommodated! <grin> Note, with this approach I think it would make sense to create a second mail alias that does the same checking but returns parsing results to the sender rather than forwarding to the list. Ie. people could use that to check things out if their patches aren't "getting through" without the regular list-server having to bounce mails (like a bad spam filter). Just my $0.02. Cheers, Geoff -- Geoff Thorpe geoff(a)geoffthorpe.net http://www.geoffthorpe.net/
Geoff Thorpe wrote:
Couldn't the wine-patches list server simply pull the emails apart and reconstruct them according to some simple rules? I'm no Perl hacker, but I'm sure this could be stitched together easily by someone who is.
I think I can do that. What I suggest: Attachments must be either .diff or .patch. If you want, they can be bz2 or gz compressed. Mime type is disregarded. Also, the mail must be non-HTML (or, at least, must have a text only component). Emails that don't qualify are bounced. Emails that do qualify are checked. If the mime type is "text/plain", and the extension is .diff or .patch, the mail is passed through. If the email has a different mime type, or is compressed, it will be extracted and uncompressed. If it has an HTML component, it will be stripped. It will then be remailed (this time passing the filter, as it is text only). I'm willing to give it some time, but only if the people in power say that they are going to implement it. Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
On Thu, 9 Oct 2003, Shachar Shemesh wrote:
I think I can do that. What I suggest: Attachments must be either .diff or .patch. If you want, they can be bz2 or gz compressed. Mime type is disregarded. Also, the mail must be non-HTML (or, at least, must have a text only component). Emails that don't qualify are bounced.
Yes, historically there are few such emails, so there will be few bounces. Another way of looking at it is that since they are so rare, we can just let them through without any processing, I'm sure someone on the list will reply to it. I think this is better aproach: just don't do any processing on messages that are 'strange'.
Emails that do qualify are checked. If the mime type is "text/plain", and the extension is .diff or .patch, the mail is passed through.
Well, I'd say that is the attachment looks like text (regardless of the mime type), simply inline the patch. Once again, an inline patch is so much better, one can easily reply to it, etc.
If the email has a different mime type, or is compressed, it will be extracted and uncompressed. If it has an HTML component, it will be stripped. It will then be remailed (this time passing the filter, as it is text only).
No need to strip anything. As I said above, let's simply ignore messages with more than one attachment. They are far and few in between, I don't think they are a problem. -- Dimi.
Dimitrie O. Paun wrote:
On Thu, 9 Oct 2003, Shachar Shemesh wrote:
I think I can do that. What I suggest: Attachments must be either .diff or .patch. If you want, they can be bz2 or gz compressed. Mime type is disregarded. Also, the mail must be non-HTML (or, at least, must have a text only component). Emails that don't qualify are bounced.
Yes, historically there are few such emails, so there will be few bounces. Another way of looking at it is that since they are so rare, we can just let them through without any processing, I'm sure someone on the list will reply to it.
I think this is better aproach: just don't do any processing on messages that are 'strange'.
What about emails that don't carry any recognized attachment at all? What if someone sends their stuff as "mychanges.myformat", or even "mychanges"? I don't think we can afford to process them, as it may lead to strange results.
Emails that do qualify are checked. If the mime type is "text/plain", and the extension is .diff or .patch, the mail is passed through.
Well, I'd say that is the attachment looks like text (regardless of the mime type), simply inline the patch. Once again, an inline patch is so much better, one can easily reply to it, etc.
I don't think that's a good idea. I think "looks like text" is difficult. I don't know how Japanese resources look like, nor how Keyboard layouts in Spanish. I'd rather go with the file extension. Also, my mailer quotes attachments with the correct mime type properly. Attachments are less likely to get garbled, and so are preferred by me. I understand why you don't like them, as many mailer give incorrect mime type that causes your mailer to handle them incorrectly. I think this filter will solve that problem. Now, my main objection to inlining is not relevant here either. As the inlining is done by a filter, there is no risk of line wrapping. Still - I think people should be encouraged to send in the same format they usually receive. How about this - I'll keep them as attachments. If we find out people can't reply to them, we'll change it? I'll also make sure that messages that have inline patches are passed as is, so that your favourite method will still be supported. Sounds good?
If the email has a different mime type, or is compressed, it will be extracted and uncompressed. If it has an HTML component, it will be stripped. It will then be remailed (this time passing the filter, as it is text only).
No need to strip anything. As I said above, let's simply ignore messages with more than one attachment. They are far and few in between, I don't think they are a problem.
I think they way people learn what to do is by receiving feedback. This is a chance to automate the feedback mechanism. I'm still waiting to hear from someone in charge of the mailing list that such a filter will be integrated if I write it. Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
On Thu, 9 Oct 2003, Shachar Shemesh wrote:
I don't think that's a good idea. I think "looks like text" is difficult. I don't know how Japanese resources look like, nor how Keyboard layouts in Spanish. I'd rather go with the file extension.
file(1) is your friend. Mime types are completely unreliable, and I see no point into forcing people use specific extensions.
How about this - I'll keep them as attachments. If we find out people can't reply to them, we'll change it? I'll also make sure that messages that have inline patches are passed as is, so that your favourite method will still be supported. Sounds good?
No, it doesn't. I can't easily reply to a message with an attachemnt, in that the attachemtn is not being quoated in the reply. Not Good (TM). I see no point in having such a filter if we don't do inlining, really.
I think they way people learn what to do is by receiving feedback. This is a chance to automate the feedback mechanism.
I wouldn't worry about it for now. Let's see what we get out of the filter first, I have a strong suspicion there will be _very_ few emails that would need 'bouncing'. At which point an email from a real person is more polite and a better feedback. If we keep having a problem, we can think of automating it, but until then it's a solution looking for a problem. -- Dimi.
Glad to hear someone is taking this up! :-) As for the approach, I think if you do take the approach of letting "unmatched" emails through, you should perhaps mangle the subject or prepend some template text to the body of the email. Otherwise it's less clear that someone will send a polite note to the author, and I rather think people will just wonder why the list looks like it did before the filter was introduced. :-) As for the inlining/attachment argument, I assume that what is needed is something that makes "wine-patches" have a more standardised look/feel/use, like "wine-cvs". I would have personally thought that attachments make more sense, because separating patches from text can be ambiguous and it's not as easy to send multiple patches (eg. when submitting two alternative patches?) Then again, I'm not the biggest contributor or tester to wine-patches, so my opinion doesn't count for squat. :-) At the other extreme, Alexandre's opinion counts more than anyone's, because of all people he's the one that needs the smoothest experience with the patches. So perhaps it'd make sense for him to make a call once the filter's ready to start breaking down and reconstructing emails in some templated format? On October 9, 2003 06:00 pm, Dimitrie O. Paun wrote:
On Thu, 9 Oct 2003, Shachar Shemesh wrote:
I don't think that's a good idea. I think "looks like text" is difficult. I don't know how Japanese resources look like, nor how Keyboard layouts in Spanish. I'd rather go with the file extension.
file(1) is your friend. Mime types are completely unreliable, and I see no point into forcing people use specific extensions.
I rather think that you need a prudent mix of both to take a decent swipe at most mailers, both in terms of dismantling incoming mail and formating outgoing ones. You could simply hack a series of pattern-matching rules on *anything* that seems relevant, and evolve them as you go. This is provided (as I mentioned earlier) you change something in the email to make it obvious that it "matched no filter", that way people know who need's sorting out and also when it might be appropriate to adjust the filter's logic.
How about this - I'll keep them as attachments. If we find out people can't reply to them, we'll change it? I'll also make sure that messages that have inline patches are passed as is, so that your favourite method will still be supported. Sounds good?
No, it doesn't. I can't easily reply to a message with an attachemnt, in that the attachemtn is not being quoated in the reply. Not Good (TM). I see no point in having such a filter if we don't do inlining, really.
Really? You're using pine I guess, from those headers. I would have thought this would have worked if the mime types were generated consistently and the MUA configured. But before we start debating as style police, is a choice even necessary? If there's going to be a mail filter able to do style-police on all mail-traffic, what is to stop it being able to generate more than one possible output? I don't know what the list server is, but it should be possible to have different preferences. Then again, if the filter takes place prior to mail-list processing maybe just splitting the list into multiple "channels" makes more sense, where you default to one of them but can change it via the preferences/unsubscribe administration. BTW: this is exactly what happens for people wanting daily digests instead of individual postings.
I think they way people learn what to do is by receiving feedback. This is a chance to automate the feedback mechanism.
I wouldn't worry about it for now. Let's see what we get out of the filter first, I have a strong suspicion there will be _very_ few emails that would need 'bouncing'. At which point an email from a real person is more polite and a better feedback. If we keep having a problem, we can think of automating it, but until then it's a solution looking for a problem.
Perhaps. Bouncing is certainly a bad idea, because a mail-list (being archived and widely read) is exactly the kind of email address that gets picked up easily by a virus so I don't think they should ever emit rule-based bounces, we've seen what happens with those damned spam filters. Instead, either forward them on as-is but with some noticable "flag" added, or /dev/null it. In the latter case, you could get around the obvious objection by creating another mail-alias that follows the same rules as the list-server but responds to the sender with parsing results. Cheers, Geoff -- Geoff Thorpe geoff(a)geoffthorpe.net http://www.geoffthorpe.net/
On October 9, 2003 09:58 pm, Geoff Thorpe wrote:
look/feel/use, like "wine-cvs". I would have personally thought that attachments make more sense, because separating patches from text can be ambiguous and it's not as easy to send multiple patches (eg. when submitting two alternative patches?)
It is strongly discouraged to send multiple patches. It has been discussed before multiple times, please search the archives. This is not something new, it has been discussed in other places (like the linux-kernel), multiple times, and every time we reach the same conclusion: the ideal situation is to have the patches inlined (patch takes are of extracting it just fine). The next best thing is attachment as text/plain, but not nearly as desirable as inline patches.
preferences. Then again, if the filter takes place prior to mail-list processing maybe just splitting the list into multiple "channels" makes more sense, where you default to one of them but can change it via the preferences/unsubscribe administration. BTW: this is exactly what happens for people wanting daily digests instead of individual postings.
That's an idea, but it means we have to patch mailman which will make future updates harder (unless mailman has provisions for such extensions). Maybe we convince them to integrate such a feature in the next release :) -- Dimi.
On October 9, 2003 10:54 pm, Dimitrie O. Paun wrote:
On October 9, 2003 09:58 pm, Geoff Thorpe wrote:
look/feel/use, like "wine-cvs". I would have personally thought that attachments make more sense, because separating patches from text can be ambiguous and it's not as easy to send multiple patches (eg. when submitting two alternative patches?)
It is strongly discouraged to send multiple patches. It has been discussed before multiple times, please search the archives. This is
The submission and processing of patches is not something totally alien to me, though the specific history and conclusions reached w.r.t. wine mail lists is. That said, you needn't crusade the inlining argument by dispatching me to the list archives about whether multiple patches are "discouraged" or not. Email, attachments, patches, and mail-lists are tools, not religions - hence any filter, such as that which we are discussing, should be there to help people receive what is easiest for them to use and not to stuff dogma down their throats. If I have three small alternative fixes to the same file, I will send an email explaining the situation with the three patches attached - not even Linus Torvalds would get far in convincing me that this is "Wrong(tm)". The point is, how can we (Shachar in particular) utilise a bit of perl tech in the mail server to make this easier for you, Alexandre, and others who have particular requirements/preferences/etc, whilst tolerating as many different "styles" of submission? This is surely the point, no?
not something new, it has been discussed in other places (like the linux-kernel), multiple times, and every time we reach the same conclusion: the ideal situation is to have the patches inlined (patch takes are of extracting it just fine). The next best thing is attachment as text/plain, but not nearly as desirable as inline patches.
Anyway, I appreciate your point, but I personally maintain (ie. my opinion, for what (little) it's worth) that attachments are the best means by which to attach files to emails - without line wrapping, and with suitable MIME types to allow proper handling (my mailer will pretty-print attachments that look like patches, for example). Also, it will be easier for a mail filter to inline an attached text/plain file than to extract and attach inlined patches. In many mail clients, the email itself is not readily accessible as a raw file for piping through an appropriate cmd-line - on the other hand, the attachments are often neatly listed, extension/mime-type registered *as* patches, and even drag-n-droppable to CVS/diff tools. The primary (valid) objection to this is that "MUAs do it inconsistently so that it is too unreliable", but that is one of the reasons for embellishing the list-server with a filter like what we're suggesting. The conclusions you refer to about patch submissions in the past have, presumably, centred around the premise that you need to standardise it because WYSIWTG (what you send is what they get). In that case, I agree that you are forced to put rules/standards in place to avoid chaos. But right now we are discussing a filter for the express purpose of being more tolerant in what is accepted, and more helpful/consistent in what is generated. I happen to think this makes more sense than forcing people through a dedicated patch/ticket management system, yet has many of the same advantages of abandoning traditional mail-lists (eg. you have less scope to "get it wrong"). BTW: another example - we could perhaps detect context diffs and, as with emails that don't satisfy any filter rules, prepend some banner text to the email body noting that the patch seems to be of an inappropriate format and should be resubmitted as a unified diff. Alexandre and the rest of us could simply ignore such postings without passing any comment, the submitter will see the bannered post turn up soon enough and can resubmit something better.
preferences. Then again, if the filter takes place prior to mail-list processing maybe just splitting the list into multiple "channels" makes more sense, where you default to one of them but can change it via the preferences/unsubscribe administration. BTW: this is exactly what happens for people wanting daily digests instead of individual postings.
That's an idea, but it means we have to patch mailman which will make future updates harder (unless mailman has provisions for such extensions). Maybe we convince them to integrate such a feature in the next release :)
It would make sense for it to support extensions like that. Just as you prefer inline patches on wine-patches, I'd like to see either inlined or attached patches on wine-cvs mail-outs rather than a URL. OTOH: I fully understand why the commit script's default action is to only send a URL, but as disk space and bandwidth are not (yet) a pressing concern for me I'd find it more convenient to just see the committed patch there. Again, I think the use of filters and value-adds like this is to give people what they want (and tolerate difference in what they send), rather than shackling them with the shared limitations of email, mailcap, and the consequent rules and regulations we use to get by amid the mess. 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? :-) Cheers, Geoff -- Geoff Thorpe geoff(a)geoffthorpe.net http://www.geoffthorpe.net/
On Fri, 10 Oct 2003, Geoff Thorpe wrote:
The submission and processing of patches is not something totally alien to me, though the specific history and conclusions reached w.r.t. wine mail lists is. That said, you needn't crusade the inlining argument by dispatching me to the list archives about whether multiple patches are "discouraged" or not.
I haven't dispatched you to the archives to be rude, but to avoid rehashing the same arguments over and over again. Saving time is important, at least in my books, as I have a chronic lack of it :) My point is that most of the people here, in particular Alexandre, prefers inlined patches for many reasons, some of which I've outlined already. I really don't understand why we have this entire argument in the first place. One thing that is certain is that one wine-patches we would like *ideally* to receive patches inlined. As you say, the point of having such a filter is to accomodate as many different "styles" of submission, and we do that by translating all those style (if possible) to the prefered style, and that one is inlined. So we have two orthogonal things here: 1. Should we have such a filter? 2. Should we dissus the prefered style? I don't think I'd like to reopen the n-th time the discussion about (2), but if you feel you have good arguments... BTW, the purpuse of wine-patches is twofold: 1. For Alexandre to apply a patch. He has spoken before, and he prefers inlined patches; (please read the section on style http://www.winehq.org/site/docs/wine-devel/style-notes ) 2. For others to review patches, and again, inlined patches are better. The case of multiple patch submission is a red herring. In the 7 years I've been with the project, I haven't seen a single case of someone submitting alternate patches. Yes, there were people submitting mutliple (separate) patches as one email, but this is strongly discouraged, as I've already said. And even if that happens, just letting them be would nicely take care of things. -- Dimi.
FWIW: I'm away soon for a few days, so you'll have to continue this without me (a fact which is no doubt to your infinite relief :-). On October 10, 2003 11:27 am, Dimitrie O. Paun wrote:
On Fri, 10 Oct 2003, Geoff Thorpe wrote: [snip] I haven't dispatched you to the archives to be rude, but to avoid rehashing the same arguments over and over again. Saving time is important, at least in my books, as I have a chronic lack of it :) My point is that most of the people here, in particular Alexandre, prefers inlined patches for many reasons, some of which I've outlined already.
Sure, I understand that.
I really don't understand why we have this entire argument in the first place. One thing that is certain is that one wine-patches we would like *ideally* to receive patches inlined. As you say, the point of having such a filter is to accomodate as many different "styles" of submission, and we do that by translating all those style (if possible) to the prefered style, and that one is inlined.
I would correct that to "and we do that by translating all those styles (if possible) to a prefered style, and that one is what each reader finds easiest to use." It's perfectly clear that some people with certain mail setups prefer inlined, and some prefer attached. Any argument with that? Insignificantly perhaps, I prefer attachments because they are decidedly easier for me to use; I can file-browse into my CVS repository, drag-n-drop the diff, and get a multi-panelled color dialog showing me the before-and-after picture. I can't do that with the original email itself, nor can I browse the diff itself with syntax highlighting without first manually extracting the patch from the email. If only one list-server output is possible, inlined patches will be the norm. If more than one is possible, wine-patches will be a better service for more people. Feel free to disagree with that logic, but it seems pretty clear to me. BTW: if delivery of wine-patches to your own address generated inlined patches anyway, would you object on any non-philosophical grounds to *submitting* your patches as attachments anyway? You are expressing a preference after all for how you prefer to receive patches, so would you similarly accommodate other people's tastes if it made no difference to you? No matter what you're receiving/processing list mail with, I think sending with attachments is universally pretty easy, and as I say it is very difficult to extract patches from an email except by passing the raw mail data directly through 'patch', which you may not want or be able to do in some setups.
So we have two orthogonal things here: 1. Should we have such a filter? 2. Should we dissus the prefered style?
s/preferred/default/
I don't think I'd like to reopen the n-th time the discussion about (2), but if you feel you have good arguments...
Only that there are indisputably situations where attachments are easier and more flexible to use, though they happen not to be your situation nor Alexandre's (using your current setups). The question is; is wine-patches a service *to* as many people as possible, or is it a sevice for a couple of core developers *from* as many people as possible? That's not rhetorical, I think it's an open question. Open source increasingly dissolves the traditional roles of developers and users and, as far as wine is concerned, I am one of these new byproducts: a "participant". Do I help wine or does wine help me? The answer: neither and both. My preferences count, but to who? and how?
BTW, the purpuse of wine-patches is twofold: 1. For Alexandre to apply a patch. He has spoken before, and he prefers inlined patches; (please read the section on style http://www.winehq.org/site/docs/wine-devel/style-notes )
I think we're agreed that one of the major roles of such a filter would be to produce more consistent output, and being able to consistently inline patches would clearly be one of the most valuable features for people like yourself and Alexandre. No argument here.
2. For others to review patches, and again, inlined patches are better.
For some, this is indeed true. But could I have them as attachments please? :-)
The case of multiple patch submission is a red herring. In the 7 years I've been with the project, I haven't seen a single case of someone submitting alternate patches. Yes, there were people submitting mutliple (separate) patches as one email, but this is strongly discouraged, as I've already said. And even if that happens, just letting them be would nicely take care of things.
Reality check: dereferencing a NULL pointer is "strongly discouraged", receiving multiple patches in an email is "marginally annoying and should have a damned good reason". C'mon, this is open source, *nix, and the uber-world - when did we all suddently turn into puritans and forget that we can be flexible precisely because we control our systems and tools and have a choice of what we use and how we prefer to operate? Concrete rules and "don't touch" inflexibility, that sounds a lot like Microsoft. Cheers, Geoff -- Geoff Thorpe geoff(a)geoffthorpe.net http://www.geoffthorpe.net/
Geoff Thorpe <geoff(a)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. 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. -- Alexandre Julliard julliard(a)winehq.com
On October 10, 2003 01:48 pm, Alexandre Julliard wrote:
Geoff Thorpe <geoff(a)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(a)geoffthorpe.net http://www.geoffthorpe.net/
participants (7)
-
Alexandre Julliard -
Dave_Belanger＠cimmetry.com -
Dimitrie O. Paun -
Dimitrie O. Paun -
Geoff Thorpe -
Shachar Shemesh -
Sylvain Petreolle