Open Bug 60981 Opened 24 years ago Updated 2 years ago

Multipart news messages: no combine and decode

Categories

(MailNews Core :: Networking: NNTP, enhancement, P3)

enhancement

Tracking

(Not tracked)

Future

People

(Reporter: xraytwo, Unassigned)

References

(Blocks 5 open bugs)

Details

From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20001122 BuildID: 2000112204 There seems to be now way to combine and decode attachments into a single file. Reproducible: Always Steps to Reproduce: Open Newsgroup Actual Results: Nothing Expected Results: A combine and decode command should be implemented (with either toobar, right-click mouse or keyboard command)like Internet Explorer to combine images, media files, etc
Changing qa assign. Seth, I believe the reporter is requesting for attachments that are broken up into smaller uuencoded parts for posting and to have the ability to re-assemble them when saving. This feature has been requested every project. Nominating bug.
Keywords: mail2
QA Contact: esther → pmock
Status: UNCONFIRMED → NEW
Ever confirmed: true
adding mscott, bienvenu and putterman to the cc list. seems to be a common request. can someone point me to a newsgroups with message that are broken up across news postings?
Not sure, perhaps you could search for a newsgroup with tentacles in the name :-)
marking nsbeta1-
Keywords: nsbeta1-
Target Milestone: --- → Future
Seth, if you need a newsgroup with attachments split across postings, go to any group that has "multimedia" in the title. Usually large files are split up like this (i.e. don't use a 56K modem) If you download one of the freeware news programs out there you should be able to post messages like that as well, and then could test them yourself.
4.x had this I believe? Will this apply to mail as well as news or should a seperate bug be opened for that? I have a funny word doc lying in my inbox split into 12 parts. Will forward it upon request if somebody needs it for testing.
hm. Is this bug 11079?
Yep, this is definately a dupe of bug 11079, but I don't have permission to mark it as such. I'm going to go ahead and move my vote, though.
I'm marking bug 11079 a dup of this one. Earlier bug number is just one of the reasons to mark as dup. This bug has more people CCd, and more discussion. (It is also assigned to someone.) Changing platform and OS to all. Removing nsbeta1 nomination since it is really old. Not sure whether this qualifies as mail2, but leaving that there since someone might be using it.
Keywords: nsbeta1-mozilla1.2
OS: Windows 2000 → All
Hardware: PC → All
*** Bug 11079 has been marked as a duplicate of this bug. ***
*** Bug 102960 has been marked as a duplicate of this bug. ***
Changing summary to avoid dupes.
Summary: No combine and decode → Multipart news messages: no combine and decode
I believe the author meant Outlook Express. To see a sample of this behavior go to alt.binaries.startrek in Outlook Express and test "Combine and Decode". One drawback of Outlook Express is that some posters use: mediafile.000 mediafile.001 mediafile.002 mediafile.003 It would be nice if Mozilla could combine and decode those. BTW - I will continue to use Outlook Express until this feature is implemented. That probably goes for many other people.
any progress on this ? im forced to use forte agent for good multipart decoding, netscape couldnt do it neither. this would be a big feature improvement
First of all, can we have a newsgroup called netscape.public.mozilla.mail-news.testcombine? That way we can upload some binaries to split in order to test this. I use combine and decode a lot on news readers for movies and large images... I have also written a perl script for combining them. Therefore, I have experience in this field. :-) In these newsgroups, I have heard plenty of people say that they don't use Netscape mail because it doesn't support this feature. That basically makes Mozilla a non-alternative in most alt.binaries groups. The spec should be as follows (you could call this a prelimary draft): Preview Pane: Headers with attachments should show it has an attachment. The size of messages should be displayed in the headers frame. Messages: Messages that are parts of a server-split message - but not the first part (i.e. - a large message that is split by the server) should not show garbled nonsense. Is it possible to detect if an image has been split by the server? Selecting multiple headers: Shift-highlight and Ctrl highlight should be a way to select multiple headers. Also, there should be a way to put on a Ctrl-lock so that you don't have to hold down Ctrl. The most recently clicked message should be shown. For instance, if you shift, highlight five messages (or ctrl-highlight), the message you clicked on to end the multiple selection should be shown. The attachments section should be larger - allowing you to see more attachments at once. It should also have 2 panes. In one pane, it shows only the attachments of the last header you clicked on. In the other pane, it should show all attachments, including that one. You should have the ability to sort them by filename, by message date, by attachment size, or by your selection order. If they are not downloaded already, they should still be listed as an attachment, with lighter text. UI: Add to context menu of preview pane: Save > Message Body... Attachment... Multiple Message Bodies... Multiple Message Attachments... View Attachments... Combine and View... Add to context menu of attachments pane: View... Combine and View... The reason I included the save part is because Microsoft lumps both combine and decode together with saving multiple attachments. IE: the only way to save multiple attachments with Outlook Express is to combine and decode, which is inconvenient. Another thing is I believe for the sake of combine and decode, the save dialog should be improved for messages and attachments. Because of this, I think it should be mentioned in this bug (but maybe branch off it). This is also the reason I included an option to view without combining and decoding. The save window should be like the one in Outlook Express allowing selection and ability to view the selected files in the view window: +--------------------------------------+ | Mozilla - Save | +--------------------------------------+ | Files: +------------------------+ | | | File 1 | | | | File 2 | | | | File 3 | | | +------------------------+ | | [Select All] [Select None] | | | | Location: _______________ [Browse] | +--------------------------------------+ You should also be able to rename files by right-clicking on them. The location of the last save would be remembered. When only saving one file, the location should also include the filename it will save it as. The Browse dialog would let you choose not only the directory but filename. This also includes when only one file is selected. When saving multiple files, the location should only be the directory. Please never use the Windows directory selection box as it doesn't allow you to create directories. I filed bug 126202 on that issue. Downloading Window (for view): +------------------------------------------------------+ | Downloading - Message Name [Y%] - Mozilla | +------------------------------------------------------+ | Downloading File X of X - FileName.Ext | | Current File: X% [ ] | | Total: Y% [ ] | | [Cancel] | +------------------------------------------------------+ Total Should reflect any files that have already been downloaded. Combine and decode: +------------------------------------------------------+ | Combine and Decode - Message Name [Z%] - Mozilla | +------------------------------------------------------+ | Downloading File X of X - FileName.Ext | | Current File: X% [ ] | | Total: Y% [ ] | | | | Combining: | | [ ] | | [Cancel] | +------------------------------------------------------+ +--------------------------------------------------------------------------+ | View - Message Name - Mozilla | +--------------------------------------------------------------------------+ | Files: +--------------------------------------------------------------+ | | | Blah.mpg Blah.jpg Blah.avi | | | +--------------------------------------------------------------+ | | []Only View selected Select: [All] [None] [See associated Messages] | | | | View: | | +----------------------------------------------------------------------+ | | | Contains all viewable files. | | | | | | | | | | | | | | | | | | | | | | | +----------------------------------------------------------------------+ | | | ---------------------------------------------------------------------------+ The Message Listed in the title bars (Message Name) is the one you last clicked on. Iconic View would be nice for the files list. Implementing the front end for bug 60446 by adding a new widget type (i.e.) <iconic> would go nicely. Notice that bug 122581 means that it will be very bad if too many images are viewed at once. It would be nice if that bug were fixed. Placeholders should be added for non-viewable files (i.e .dat, etc) in the View Frame. On combine and decode of server-split messages, No garbled nonsense should appear in the view window even if decoding failed. The context menu for items in the iconic view should be: Open Save Save Selected Save All See associated Messages will bring up a Preview Pane/ Message Window for all messages that contained the files that were either viewed or combine and decoded. You should be able to combine and decode/view multiple files at the same time. Therefore, while you are downloading and/or combining, it shouldn't be modal as is the case for Outlook Express. Just like Outlook Express, it should also have the view window non-modal. When you are downloading/combine and decoding multiple files, it should share bandwidth between them and not do them serially. It should also share bandwidth with anything downloaded in the main message window. The reason for this is because you might be combine and decoding some huge file while you want to view some other smaller file. MPT: Feel free to tear this apart ;-) Back End: Sharing bandwidth for multiple combine/decodes. Combining: This is the best way to do combining imho: - It should combine as it downloads files. - Combining shouldn't be done consequetively for files too large to combine in mem. I don't know if the following is necessary. If there is an open file handle, and you just send the data out to the file, maybe the operating system would do it efficiently enough that you wouldn't have to worry about it. Any comments? File.dat.1 File.dat.2 File.dat.3 ... File.dat.80 It shouldn't do the equiv of this: copy File.dat.1 File.dat copy File.dat + File.dat.2 File.dat etc That is way slower (at least on Windows) than making a group of intermediary files (such as 10) that you copy only 8 files to. Therefore, now the 80 files would become 10. Those last 10 would then be combined. This means that you are not re-copying that huge file each time. Perhaps having multiple steps would be even better. For instance, if you had 800 files to combine, you would get 100 intermediary files, which would still be unwieldy. In that case, it would be nice to create a new set of intermediary files. Some thought needs to go into this. The important factor is that we don't want the same thing to be copied over and over. A way should be found using intermediary files that decreases the total number of bytes copied. I'll clarify this: File.1 1MB File.2 1MB File.3 1MB File.4 1MB Doing it serially, you copy 1MB, then 2MB, then 3MB, then 4MB. This gives a total copy of 10MB for a 4MB file. Doing it in two parts means you copy 2MB then 2MB then 4MB. That gives a total copy of 8MB for a 4MB file. Better. I think 2 at a time would be the best way. Again, I repeat this might not be necessary. It all depends on how operating systems handle writing to the end of very large files. If we can just stream data out to the file, then the following should be done: An empty file the size of what the finished file should be can be created (this is also a good disk space test). *If a combine is canceled, or if Mozilla crashes, the file should be deleted. Any unfinished combines should be detected on Mozilla startup to determine if there was a crash and the created file should be deleted* As the files are downloaded, that location in the file should be seeked to and written to. Already downloaded files should be added right away. The way to determine how files should be combined: 1) Split messages can be combined. Ordering is done based on message names. They will contain identical names except something like: 0/2, or 1/2 - Be careful, some people do some really wierd things such as having the first one 2) Files such as the following can be combined: file.ext.#1 file.ext.#2 file.ext.#3 file.#1.ext file.#2.ext file.#3.ext Where # is any number of leading zeros If any files seem to be missing, the user should be notified and asked if he wants to continue. I'm wondering if there should be a way to do a user-defined combine where the user selects the order of combining attachments and Mozilla doesn't. Should this be a seperate bug? I probably listed a dozen things here that should be split off into other bugs. What do you think?
yEnc multipart messages should also be supported: http://bugzilla.mozilla.org/show_bug.cgi?id=119964
If mozilla supports this (hopefully better than IE's sketchy support) and also bug 119964, I imagine we can pull the rug out from under Outlook Express if they are slow in implementing yEnc.
<spam>I meant OE, not IE.</spam>
if you are aiming for marketshare from Outlook Express, also consider: http://bugzilla.mozilla.org/show_bug.cgi?id=25694
QA Contact: pmock → esther
I would like to add to this conversation that is IS possible tio get rudimentary saving of multi-parts in Netscape 4.x... 1 - Choose sort by subject. 2 - save as... "BLAH.uue" 3 - Double-click with Winzip (or use other standalone decoder) While this is a slightly manual process, Mozilla doesn't even allow this much... NOTE: occaisionally a multiparter does not properly declare the part boundary with begin/end codes... In such a case, the quisi-manual process works if you haul the .uue file into a text editor and strip out the newsgroup message headers. And YES, the user should be able to arbitrarily reorder the parts - sometimes posters will send with non-proper-sorting subject names. ADDITIONAL NOTE: not all multiparters use UUENCODING... there are 1 or 2 other encodings that get used sometimes.
*** Bug 160359 has been marked as a duplicate of this bug. ***
I found an odd way to work around this .. its atleast largely automatic .. third party program used: uud32 -- it has a fewature to stream decode a file and to check for updates .. so what I do is create a temporary local mail folder .. in this case called "tmp" .. in the news group select messages, rightclick and copy to the temporary local mail folder .. from uud32 (after moz starts downloading the files) select the mailbox data files for stream decoding .. and off it goes .. any messages copied into the temporary local folder now will be decoded and for multiparts properly assembled .. uud32 even does yEnc (I still want native support in Moz of course ;)
Why hasn't his been fixed yet? - *any* decent newsreader can combine and decode! btw: make the combine and decode work, without having to click one of the postings - which is highly annoying, since this will start dwl. This should IMO have been made for 1.0...
ARRG. People who continue to ask "why hasn't this been fixed yet" are extremely getting on my nerves. It hasn't been fixed yet because nobody has worked on it and created a patch. You're free to fix it if you want. If you can't, you're free to shut up. Thanks.
Regarding comment #24: No mater how you flip and turn this - Mozilla is the basis for Netscape. If Mozilla hasn't got this feature, it is very unlikely to be included in Netscape. Therefore it is *very* valid to ask why this feature, nay bug hasn't been "fixed". Though I agree with you that it would be best if people reporting bugs would fix it themselves, it is very unlikely. This project benifits from having *ordinary* people buggin about something that they deem they need. If this feature was something that was invalid, the bug would have been closed. It isn't - and it's fairly low numbered. I could probably have fixed this bug myself, however I have many other projects being worked on, sadly Mozilla isn't on my schedule. Another thing, 50 people are voting for this bug. This is a relatively high number, and as such this bug should be "heard". However I can see that this bug has been marked as 1.2, and I truely hope that it will be fixed by then - but sadly I have seen many bugs being moved along. This isn't a unique, unresonable RFE. It is something that most newsreaders have. A product like Mozilla/Netscape *should* have support for binary newsgroups.
Please do not add a bunch of "me too" and "where is this" comments. It doesn't help the developers get things fixed any faster. If you have an insight as to how to fix the bug, or want to supply a complete patch yourself, please do so -- but spam doesn't help anyone. You can determine the likelihood of this bug getting fixed by looking at the Priority and Target Milestone Information. This bug has a Priority of 3 which means that it will be looked at after bugs with a priority of 1 or 2 have been investigated. At the moment the developer in charge of this bug has no set time-range for this fix, and has thus indicated a milestone of Future. Managers will probably begin a search of all bugs marked moz1.2 shortly and will determine whether to raise or lower this bugs priority at that point. I am fairly sure that this bug's importance stands on its own for when that time comes around and doesn't require any comments that "encourage" developers to fix it.
Brian, adding such comments to bugs is useless. There are two groups of developers: Those that are paid for working on Mozilla. They get told by their managers what bugs to fix. Now, they decide which bugs to fix by the feedback they get (through Netscape's feedback page, or newsgroups, or whatever). It seems unlikely to me that a few bugzilla comments would make them reprioritize their employee's work. The second group is those who do not get paid. They fix bugs that are easy to fix, or interesting to fix, or so. However, if they see >50 comments many of which are "please fix this", so that the important comments get lost, usually are not bugs which people like to fix. So, commenting in bugs makes it less likely that it gets fixed.
I'd like to add something to the previous statements... That is what the vote feature is for. Also, see bug 164310 I just created for a feature to allow people to add the reason for their votes.
Brian: Combine and decode (along with the necessary inclusion of yEnc that will make it a non-useless inclusion) is no small-fry fix. Sure, someone could hack together something quick that could do the job, but it probably wouldn't be doing it the best way. I have been researching how it is done on many newsreaders and also what I see wrong with each of these implementations. Of course, none of this really matters until we support yEnc. I would make this bug depend on yEnc except that there might be an occasional non-yEnc multipart posting. yEnc: bug 119964. I also created yEnc.mozdev.org. Realize that lots of people who don't work on this project as a Netscape employee have to fit in their work within all the other stuff they have to do because they are only volunteers. Although I would love to work on this project and a few others 24/7, I have to support myself, and that means a job. I'm sorry if we are not working fast enough. Why don't you find someone who is willing to pay us so we don't have to do another job and can work 100% on Mozilla.
Blocks: majorbugs
Well, it is not the full implementation of features requested by this bug, but I notice that the forward as attachment already does the combining part - can someone canabalize (sorry, that should be code reuse ;-) the code from the forward as attachment logic and splice it into the file->save (as) code to at least allow for multi-mail saves? That would appear to handle 1/2 of what is requested, and at least get those poor users off of NS4.8(-).... Perhaps the combining part could be handled by a generic "send-to" paradigm much like send-to is handled in windows - you register a couple of applications as being send-to handlers - either as endpoints of a datastream composed of the selected emails concatenated together, or you could just use the multi-save feature above to save to a temp file that is launched the same way that Moz currently "opens with application". As far as where the UI would be put, I guess you could put it in the file->save contexts/menus or maybe in the "tools" menu as send to (or "Open with application:" and list the various registered "generic" apps). This would allow for all sorts of helper apps to work with Mozilla even if there isn't direct support for it, or it is a protocol Mozilla doesn't want to support natively (e.g yEnc, etc.).
This comment complements Todd Pederzani's comment of 2002-12-02 in Bug 71189: Bug 71189 "[RFE] Ability to Decode message/partial Messages" seems to be the Mail equivalent of this bug. The fix might be related.
sorry, still no plans to do this work. mozilla does have the ability to decode uuencoded messages (but not ones that are broken across several messages) note to self on where to find that code: C:\trees\trunk\mozilla\mailnews\mime\src\mimeenc.cpp(427): if (!nsCRT::strncmp (line, "begin ", 6)) C:\trees\trunk\mozilla\mailnews\mime\src\mimeenc.cpp(715): PR_snprintf(firstLine, sizeof(firstLine), "begin 644 %s\015\012", data->filename ? data->filename : ""); C:\trees\trunk\mozilla\mailnews\mime\src\mimeunty.cpp(403): if (nsCRT::strncmp (line, "begin ", 6)) return PR_FALSE; C:\trees\trunk\mozilla\mailnews\mime\src\mimeunty.h(58): if line is "begin 644 foo.gif"
to elaborate, I'd like to get to it, but it's not on my radar yet. I'm working on bug fixes (starting with the nsbeta1+ bugs, but also handling any regressions or blockers) and finishing up the junk mail and mail views features. I do want this, (so I'd accept patches) but other things have higher priority. marking as an enhancment. 4.x did have this, but OE does (I think)
Severity: major → enhancement
s/4.x did have this/4.x didn't have this
Outlook Express, Agent, and Binary News Reaper all have it. Whoever does implement this, try not to make it too imposing on the user, and it would be nice if it didn't block other activity on Mozilla or Mailnews while you were doing so. (i.e. Outlook Express has a modal combine and decode, which is annoying).
Also, Binary News Reaper allows you to change the priority of newsgroup downloads and has a queue that reflects what priority you give a download. This might be nice, but also I can see how it would be confusing if not done properly. Binary News Reaper is more of an application for advanced users. Perhaps a dumbed-down version of BNR's priority queue would be nice. See what I mean at: http://www.bnr2.org/bnrdown.html
IIRC 4.x had the ability to do this by selecting the range of messages, then doing file - save as.
The entire Communicator series has always had the option to save-as multipart binaries into one file with a .UUE extension for later decoding. One workaround is to create a new folder with a .uue extension, save all parts to this folder and decode with WinZip for example.
*** Bug 189128 has been marked as a duplicate of this bug. ***
Keywords: mozilla1.2
*** Bug 207125 has been marked as a duplicate of this bug. ***
This feature was opened on 2000. There are 3 years and this usefull feature still new! Will someone fix this or not?
It will most likely be handled after yEnc is handled.
BTW, yEnc is currently being worked on.
Just started to received emails which are split. Here's the abreviated headers... <message number=1 size=64k> <comment>Received list removed</comment> Message-ID: <002901c3d510$811f96f0$82112bd1@oemcomputer> From: <them@them.net> To: <me@me.net> References: <3FFB9DEA.3080400@me.net> Subject: Re: stuff [1/2] Date: Wed, 7 Jan 2004 06:22:14 -0500 MIME-Version: 1.0 Content-Type: message/partial; total=2; id="01C3D510.80608CB0@oemcomputer"; number=1 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-RCPT-TO: <me@me.net> Status: U X-UIDL: 352947590 From: <them@them.net> To: <me@me.net> References: <3FFB9DEA.3080400@snip.net> Subject: Re: 20040111 finance slide(s) - approval Date: Wed, 7 Jan 2004 06:22:14 -0500 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0025_01C3D4E6.97815CF0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 This is a multi-part message in MIME format. <comment>This message terminates in image data.</comment> </message> <message number=2 size=45k> <comment>Received list removed</comment> Message-ID: <002a01c3d510$8e1500c0$82112bd1@oemcomputer> From: <them@them.net> To: <me@me.net> References: <3FFB9DEA.3080400@me.net> Subject: Re: stuff [2/2] Date: Wed, 7 Jan 2004 06:22:14 -0500 MIME-Version: 1.0 Content-Type: message/partial; total=2; id="01C3D510.80608CB0@oemcomputer"; number=2 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-RCPT-TO: <me@me.net> Status: U X-UIDL: 352947591 <comment>Message begins with image data.</comment> <comment>Message ends with image data...</comment> Ae570Af/2Q== ------=_NextPart_000_0025_01C3D4E6.97815CF0-- </message> I do not know whether this is RFC 2046 compliant and you probably can not tell because of the missing data, but if it is, then the Mozilla 1.5's email client displays nothing and OE 6.0 is using IETF standards against Mozilla. This is not a good situation. Sure, I can work around this but what about Joe N User? To make matter worse I use IMAP so you need to consider that the combining operation is not always local. Maybe the workaround for now is to display something. If there is a valid mime section then display. It would have been nice to see the text even if the images were not available. FYI, Mark
UUDeview is a GPL'd Windows program which nicely provides the "combine and decode" capability that is desired here. Perhaps the author, Michael Newcomb, would be willing to help? I've sent him an e-mail. http://www.miken.com/uud/developer/source.htm
Conrad: If he's interested, but there would be a steep learning curve to be able to merge the code with Mozilla and you'd have to check on any licensing issues. I don't know if our license allows us to include GPL code. The tri-license might ony allow others to use Mozilla modules in GPL programs and distributions. I thought about the queue idea, and that seems best for a seperate bug, so I filed one. Bug 236409 - Allow prioritized queuing of News message downloads While downloading a multipart message, it will be useful to have the image progressively display as its downloaded, along with for files like .mpegs to be able to view the file before its fully downloaded. That is because .mpeg files can be viewed even if not completely in-tact (i.e. only 1MB is available of a 25MB file). That way people could just click on view or whatever, and it would load up in their media player even though its not completely downloaded. Since media programs might lock a file for write, we'd probably want to use a spool file and then allow them to copy it to another location before viewing. Multipart news messages should be "pre-joined" in the message pane, if possible to show something like: Racecar.mpg (*/28) This is something that Agent does and will make it so that multipart messages only appear as one message in the pane instead of many. In the queue tab, it should appear as probably still one file, but show how many parts are already downloaded or something like "(5MB of 20MB -- 10 of 40 parts)" Agent also features something that will tell you which parts are missing of a multipart message. Combining should occur non-modal -- i.e. you should be able to select more messages to download while you are downloading multipart messages. Combining code can be used, as I mentioned earlier, for messages that contain binaries that were split using mastersplitter. I "smart" feature to detect masterplitted files by file name could accomplish this. You could then select a file and choose, "download other parts", a dialog could pop up making sure the program automatically chose the correct parts, and then you could choose "join" or something like that. The dialog should be modal, but the actual joining should be non-modal. This might be better done seperately because mastersplitted binaries are not multipart news messages, but extension of the combining feature for this purpose should be kept in mind. More info: http://www.tomasoft.com/ Unix "split" is similiar to the functionality mastersplitter provides. Another question is: does Mozilla post multipart news messages?
(In reply to comment #47) > I don't know if our license allows us to include GPL code. it does not.
*** Bug 244094 has been marked as a duplicate of this bug. ***
*** Bug 256097 has been marked as a duplicate of this bug. ***
*** Bug 259339 has been marked as a duplicate of this bug. ***
Wow. Orignally opened in November of 2000??! Is this going to be fixed anytime soon? This really is a showstopper..
adam.schweitzer@gmail.com: thank you for volunteering, when can we expect a patch?
(In reply to comment #53) > adam.schweitzer@gmail.com: thank you for volunteering, when can we expect a patch? Huh? I don't recall volunteering for anything.. you must be thinking of someone else.
we're an open community, if you have a problem that you think needs fixing then you're encouraged to work on it, or find someone to work on it, you can put time into a problem or money, or wait patiently for someone else to do it. we don't need people complaining or otherwise spamming bugs reminding people that they're old. we don't need people threatening not to use our products. https://bugzilla.mozilla.org/etiquette.html
(In reply to comment #55) > we're an open community, if you have a problem that you think needs fixing then > you're encouraged to work on it, or find someone to work on it, you can put time > into a problem or money, or wait patiently for someone else to do it. we don't > need people complaining or otherwise spamming bugs reminding people that they're > old. we don't need people threatening not to use our products. > > https://bugzilla.mozilla.org/etiquette.html Unfortunately, my code is generally incompatible with open source licenses. That is, I expect to be paid for it. That said, if Mozilla wishes to hire me on contract to produce these features, I'd definately be open to that.
"Unfortunately, my code is generally incompatible with open source licenses. That is, I expect to be paid for it. That said, if Mozilla wishes to hire me on contract to produce these features, I'd definately be open to that." We all would. However, Mozilla.org has limited funds that currently go to qualified developers on other projects. Code developed by a for-hire programmer is not incompatible with OSS licenses though. If this bug is that important to you, and you _can_ fix it, but are unwilling to share that code, feel free to patch _your_ copy, and let the rest of us work. As it is, you're making demands that other people donate THEIR time, something you are unwilling to do. That doesn't seem fair, Adam.
I can create a paypal account for a reward to the person or persons who fix this bug. Those that are willing to donate some money specifically for this bug to be fixed could then perhaps create more incentive for this bug to be fixed faster. I do think that some day that this bug will be fixed, but right now the main developers seem more interested on the Mail program UI than anything. Let me know if you would like to donate money, and I'll set up a paypal account for it. I'll even throw in something myself. I'll keep a list of everyone who donated and how much (unless anonymously), so not only we know who donated, but also so you can trust my administration of the pool. Send me an email if you'd be interested in adding to the reward. If I don't get a cumulative/collective commitment of something substantial for a reward, it won't be worth even bothering to set it up since this is no small bugfix. Adam: Generic news client code wouldn't be compatible with the Mozilla codebase without major modifications. You could provide a binary to show that you had done some work without exposing your code. Then, if you provided pseudo-code and a description, you wouldn't be giving away your code, and would be assisting in getting this bug fixed, if your pseudo code and description of how you got it working was more than just a dangerous hack.
If this bug depends on a bounty, then does it depend on bug 124096?
Depends on: 124096
No, it doesn't. There doesn't need to be any keywords or Mozilla-based system, etc, for a private pool. Dependencies for a bug like this are technical things.
No longer depends on: 124096
*** Bug 267360 has been marked as a duplicate of this bug. ***
Product: MailNews → Core
Blocks: 272895
No longer blocks: majorbugs
I officially volunteer to actively work to fix this bug/enhansement. Doug Lane Sacramento California
I will start off by entering comments about requirements and how to scope my development effort. Comment #15 has just a ton of requirements, and as development continues that sort of mature implementation will be done (some day). So I plan (unless given some better suggestion) to start with a simple combine and decode which will be: - create a method to invoke combine/decode via a menu option - simple checks like if no messages selected, do something appropriate - show the user a dialog (pick a dir) where to save the attachments - show progress (maybe by using the code for downloads?) - error detection like out of disk, etc. One major challenge is scaling this functionality. I plan to develop the decoding by using as little memory and disk as possible by decoding "as we go" instead of caching the original messages... then decoding. I also like the practice of "never stop", I'd prefer to continue decoding by skipping to the next file to combine rather than stop. An option can added later to stop when that happens, but the default should be carry on until something really bad (or good) happens. The user can hit cancel if they wish to stop the process (just like downloading).
From Comment #15, "An empty file the size of what the finished file should be can be created (this is also a good disk space test)." This would require at least 2 passes though the messages, which would have impatient people waiting when large numbers of files (or large size files) are decoded. Another request was to see the files as they are downloaded/created, if we just do one pass then the files will be seen viewed immediately. The modal Outlook Express dialog serves a purpose, it is to order the files. I'm hoping that a small amount of guessing will allow that to be done in some 'smart' way. Since the program which is displaying the message headers may not allow people to sort which message (or newsgroup for that matter) is done first, there might be a desire to order which ones get done first.
To avoid cluttering the bug with comments about my progress, I have created a web page that indicates the gory details of a first timer and a small blurb about why with my experience, I might just be able to get it done. :) http://gaia.ecs.csus.edu/~laned/devwork
*** Bug 335115 has been marked as a duplicate of this bug. ***
Blocks: 339983
http://ed.mullen.home.comcast.net/Mozilla/moz_combine.html --> some explanation for decoding multipart message in TB/Mozilla Suite using uudeview or yenc32
sorry for the spam. making bugzilla reflect reality as I'm not working on these bugs. filter on FOOBARCHEESE to remove these in bulk.
Assignee: sspitzer → nobody
Blocks: 423488
Filter on "Nobody_NScomTLD_20080620"
QA Contact: esther → networking.news
Product: Core → MailNews Core
If this RFE isn't going to be pursued, shouldn't we mark it "wontfix"? Or would marking it wf discourage any future takers? It's been 9+ years since this was posted, seems like a dead issue to me.
No. Despite occasional misuses, wontfix has a single meaning: "if someone presented us with the perfect elegant patch for this, with complete unit tests and tests for everything else it might affect, we would say 'thanks anyway, but we're not going to check that in'." While that might or might not be true of this bug (I have no knowledge of the situation, and thus no basis for judging), wontfix never ever means "I'm bored by the fact that this bug was opened on some particular date."
As far as I can tell, the current open-source community will not prioritize this RFE and has basically told anyone wanting the function, "if you want it then YOU program it". This issue resurfaces every now and then with the same answer(s), etc. That's why I asked about the "WontFix". Thanks for the comment. I don't have the skill to do it unfortunately. Perhaps someone with the capability will come along before I stop breathing air - pushing 70 yo at the moment, please hurry. :-)
Blocks: 102960
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.