Ben Bucksch wrote:
[snip]
>> This should be a separate bug from 28327, right?
>
>
> Yes.
>
>> Does it already exist?
>
>
> File one.
Will do. But I have a question below, first.
>> 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
[snip]
> 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).
Uhm...right
For whatever reason I convinced myself that email clients send the
message to the server n times for n recipients. Not sure when I picked
up that braindead notion :/
>> 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.)
That's a power user edge case. It isn't something a normal user is
concerned about when they want to share a page. Anyhow, before I get
swatted for trying to make something true by stating it as fact, let's
consider what the use cases for sending a page snapshot are:
* archiving the page
* Web page QA
I think those are both pretty narrow use cases. There are probably some
others.
What if I want to save an archive of the page on my hard drive, not in
my Inbox? I have to "Send page" to myself and download the attachment.
It sounds like what's really needed is the ability to have "Save as"
in a browser window support saving the entire page as a multipart
bundle. Assuming that were available, you no longer need "Send page" to
send multipart, you can always do "Save as" then attach the bundle.
Of course, I've muddled UI and internal functionality together in my
argument. The internal functionality that enables "Save as" to save a
multipart bundle also enables the sending of pages as multipart
attachments. What is and isn't included in the UI for normal/power
users is, I guess, a seperate issue.
>> 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.
When you write "'saving' the page" do you mean what I suggested above
about "Save as" in a browser window? I think you do.
So where are we at? Should I add two bugs: one for viewing
multipart/related email and another to enable "Save as"|"Send page" to
save|send multipart/related files|attachments?
--
Tim Taylor
[EMAIL PROTECTED]
