I'm going to have to scale back my efforts on this bug. It no longer looks like there's a chance of making a relatively quick change (something that could be done in 2 - 3 weeks), due to the architectural complexity of Mozilla and due to my own unfamiliarity with the code base.
Even with a minimized scope for the bug - not allowing attachments to be externally saved and linked-to (detached), and not making filters to detach attachments from a mailbox) - there still remains the basic action of altering a received message, which is where the real issue is. I haven't found any signs of existing functionality that's similar to what would be needed for this bug, or any signs that Mozilla was created to in any way support this type of an action (internally modifying a received e-mail without changing the message ID). It's possible that this change would be in conflict with the originally intended behavior of Mozilla - that it was for a deliberate reason that an architectural means was not provided to accomodate this type of an action. If that's the case, that wouldn't necessarily mean that it's a bad idea to make the change for this bug, but it would require some extra effort to ensure that a change of this sort wouldn't step on too many people's toes (architecturally speaking). And it would mean that the source code for the bug might have to be created almost entirely from scratch, as the first of its kind of this sort of behavior (internally modifying a received e-mail) - meaning that it may have its own extended learning process for how to work the code in in a way that's consistent with the existing behavior of Mozilla (all the little variations of behavior that have been added in over the years to accomodate exceptions to the usual rules) (to put it another way, it might be very buggy initially with a good deal of reworking required over time). That's my assessment of the situation at this point. It's very possible that someone with a thorough knowledge of the relevant architecture of Mozilla would see things very differently, and would perhaps even see a relatively easy way to proceed with this change. For the time being, I'm still interested in pursuing the change, although now at a more gradual scaled-back pace. If I continue with the work, on my own, offhand I'd guess it'd be at least 6 months before an initial patch would be available. That amount of time could be shortened, to whatever extent that people with experience in this area of the code base are willing to help out and identify feasible ways to proceed with the work. And if someone else winds up spearheading the work on this bug, someone with a better understanding of what needs to be done, that would be fine too. The reason I've been playing that role in the last few weeks, despite not having any familiarity with the code base, is simply because there wasn't already someone doing so, and I wanted to see the bug get closer to being resolved, or at least find out if it's feasible for the change to be made. The ultimate success or failure of this bug depends on the amount of effort and feedback that others are able to offer. It's important to view this as a common group effort. With enough effort from the group, any change should be possible. -- Matt Coughlin [EMAIL PROTECTED] <remove "sp4mless_" from the e-mail address to reply>
