> Given the raw text format of a MIME mail message this feature is fairly > easy in a storage sense. I don't know what impediments the internal > Netscape data structures will present or where to add the UI hooks [...]
I've already identified how and where to add the source code to get the additional UI for the attachment list context menu and the main menu. That turned out to be pretty easy since it was just a matter of modeling it after the existing code for saving attachments. And yeah, on paper when you look at how easy it is to understand the internal layout of an existing e-mail, and when you see that it's just a plain text file, you'd think it'd be pretty simple to make the program add in another header, and delete or replace an attachment. At least, it seems like a small program or script could do it pretty easily. But so far, with no familiarity with the code base, it's been difficult sifting through the code looking for any sign of where the real functionality is for reading and writing the headers, the body, and the attachments, and understanding how the new code would have to be consistent with the existing layers of abstraction and all the exceptions to the usual rules that have been added in over the years for things like the somewhat similar actions of moving and copying e-mails. The knowledge barrier for making a change like this appears to be quite high. That's why I've stopped trying to make a quick change, and why I'm looking at a time frame of at least half a year of gradually learning a little bit at a time. It'll also be essential to proactively get help from people familiar with the relevant portions of the code base. Of course, if someone really experienced jumps in and makes a patch for this in just a few days, that would be a much better scenario (though after 3 1/2 years of this bug sitting around relatively untouched, it'd be unlikely. Ah, but one can dream :-) > I envision a change something like: > --------------050606040201070208030509 > Content-Type: image/png; > name="names.png" > [...] I think there'd be a lot of end-user considerations with this approach that would need to be looked at pretty thoroughly, if it's to be pursued seriously. In my first attempts of manually editing an e-mail to make a change like this, I got the feeling that the UI would wind up being too confusing. I'd recommend trying it out yourself manually and seeing what you think. The most I can remember right now is that it seemed a little weird that after deleting the attachment there was still an attachment there that you could possibly delete or save. It might significantly complicate the UI, and perhaps harm the intuitiveness of it, to find a way to handle this. Maybe a clean solution is possible, but I'm having trouble picturing it right now. Are you aware of any [somewhat] widely-used e-mail clients that use an approach like this for deleting or externally storing attachments? I'd also be interested in hearing other people's thoughts about this. -- Matt Coughlin [EMAIL PROTECTED] <remove "sp4mless_" from the e-mail address to reply>
