Tim 'Tool-Man' Taylor wrote:
> I'm late to this discussion. I think I've done the necessary homework
> (reading bugs 28327, 37983, 40756) and caught up on this NG.
Thanks for taking this time.
> 2. support multipart/related in composer
(Note: I think, we do support it, just only in the case of manual
addition of images.)
> So one day this won't be a problem
What do MS OE / MS Outlook do?
> Mozilla should only generate multipart/related when sending HTML mail.
Agreed, but I think, it's mostly a time (for implementation) problem.
Unfortunately, it's not that much of a priority for Netsacpe. Any
volunteers?
> This should be a separate bug from 28327, right?
Yes.
> Does it already exist?
File one.
> 4. "send page" type URL/page sharing
>
> For #4, this is a special case of the bandwidth spike problem, except
> the publisher is behind a 56k modem. User's won't understand the
> implications of clicking "Send page" on that Flash-laden,
> took-two-minutes-to-download page they want to share with their 20-50
> recipient circle. So this is a legitimate problem for having mozilla
> only send multipart/related.
I don't think so.
I think, it's not to hard to come to the conclusion that, if I really 2
mins to *download* a page, it takes 2 mins to *send* the same page.
The number of recipients is, in almost all cases, at most a problem for
the mail server, not the sender, since Mozilla sends only 1 copy to the
server (I think).
I don't think, it will be a problem for the server either - a *rare*
sending of 300K to 50 recipients is not *that* "stressing".
OK, if the sender has a broadband connection and the recipient only 33K,
the recipient might not like it, but that is not a new problem (how many
people send video attachments...).
> The solution: replace "Send page" with the functionality of "Send link".
While I think that "Send Page" is *way* over-/abused (QA, do you hear
me? :-) ), I think, it has its purpose. What, If I want to "save" the
page? (I or the recipient might want to save the email, incl. the page,
for the archive, but the original page might not persist that long on
the server.)
> With regards to sending pages, either really support offline browsing
> and send /all/ the referenced content as multipart/related, or don't
> support offline browsing and require the user to download the page
> themself. The current half-implementation is the worst of both
> worlds and has gotten us into this predicament.
I agree. The same argument applies not only to offline, but also to
"saving" the page.
--
This message is protected by ROT0 encryption and the DMCA.
Reading is disallowed and will be prosecuted.
