unofficial mirror of meta@public-inbox.org
 help / color / mirror / Atom feed
* Feature request: Support for body in mailto links
@ 2022-12-21 15:21 Siddh Raman Pant
  2022-12-21 21:04 ` Eric Wong
  0 siblings, 1 reply; 5+ messages in thread
From: Siddh Raman Pant @ 2022-12-21 15:21 UTC (permalink / raw)
  To: meta

Hello,

It would be nice if mailto links also contained the body of the
email one is replying to in quoted form (i.e. have leading "> ")
so that one can directly start replying when the client opens. It
seems the "body" hname allows this behaviour.

Thanks,
Siddh

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Feature request: Support for body in mailto links
  2022-12-21 15:21 Feature request: Support for body in mailto links Siddh Raman Pant
@ 2022-12-21 21:04 ` Eric Wong
  2022-12-22  6:43   ` Siddh Raman Pant
  0 siblings, 1 reply; 5+ messages in thread
From: Eric Wong @ 2022-12-21 21:04 UTC (permalink / raw)
  To: Siddh Raman Pant; +Cc: meta

Siddh Raman Pant <code@siddh.me> wrote:
> Hello,
> 
> It would be nice if mailto links also contained the body of the
> email one is replying to in quoted form (i.e. have leading "> ")
> so that one can directly start replying when the client opens. It
> seems the "body" hname allows this behaviour.

How many mail clients does it work on?  And do people even use
mailto: links?  It would roughly double the the size of HTML
responses for /$INBOX/$MSGID/ endpoints and probably increase
browser memory use a similar amount.

Fwiw, I'm not a fan of quoting publicly-archived mail;
especially with our "archives first" philosophy.

Quotes makes messages significantly bigger than they need to be;
thus more expensive to mirror when the replied message is
readily accessible in public archives.  I end up skipping over
quotes 99% of the time.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Feature request: Support for body in mailto links
  2022-12-21 21:04 ` Eric Wong
@ 2022-12-22  6:43   ` Siddh Raman Pant
  2022-12-22 11:28     ` Eric Wong
  0 siblings, 1 reply; 5+ messages in thread
From: Siddh Raman Pant @ 2022-12-22  6:43 UTC (permalink / raw)
  To: Eric Wong; +Cc: meta

On Thu, 22 Dec 2022 02:34:19 +0530, Eric Wong, wrote:
> Siddh Raman Pant code@siddh.me> wrote:
> > Hello,
> > 
> > It would be nice if mailto links also contained the body of the
> > email one is replying to in quoted form (i.e. have leading "> ")
> > so that one can directly start replying when the client opens. It
> > seems the "body" hname allows this behaviour.
>
> How many mail clients does it work on? And do people even use
> mailto: links?

I tried it on mutt, Thunderbird, GMail web and mobile, Outlook web,
and Samsung's mobile mail app. So it does seem to have wide support.

If mailto is unused, why would the option and its support be there
in this project, and also in proprietary clients on mobile and web?

Debbugs also has the behaviour I mentioned, you may try it on any of
their bug report email pages. For example:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1018118
(I know it's not exactly an archival project like this.)

> It would roughly double the the size of HTML
> responses for /$INBOX/$MSGID/ endpoints and probably increase
> browser memory use a similar amount.

That makes sense, thanks.

While I can't say much about performance in general (I am not much
familiar with the project internals, and came across this due to
lore.kernel.org), but regarding browser memory, the threaded view
already shows multiple messages, so I don't think it would be too
much of an issue, and the mailto links are apparently only shown
when you open permalinks.

I just tried loading on w3m an 896 KB HTML thread from lore.kernel.org
(containing 2-3 kernel configs, which you'd agree is normally huge
spam), and w3m seems to take 33MB of memory, a normal amount.

> Fwiw, I'm not a fan of quoting publicly-archived mail;
> especially with our "archives first" philosophy.
> 
> Quotes makes messages significantly bigger than they need to be;
> thus more expensive to mirror when the replied message is
> readily accessible in public archives.  I end up skipping over
> quotes 99% of the time.

Isn't quoting when replying to the convention? And most mailing lists
I have seen use quoting...

Thanks,
Siddh

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Feature request: Support for body in mailto links
  2022-12-22  6:43   ` Siddh Raman Pant
@ 2022-12-22 11:28     ` Eric Wong
  2024-11-05 19:49       ` Andrew Cooper
  0 siblings, 1 reply; 5+ messages in thread
From: Eric Wong @ 2022-12-22 11:28 UTC (permalink / raw)
  To: Siddh Raman Pant; +Cc: meta

Siddh Raman Pant <code@siddh.me> wrote:
> On Thu, 22 Dec 2022 02:34:19 +0530, Eric Wong, wrote:
> > Siddh Raman Pant code@siddh.me> wrote:
> > > Hello,
> > > 
> > > It would be nice if mailto links also contained the body of the
> > > email one is replying to in quoted form (i.e. have leading "> ")
> > > so that one can directly start replying when the client opens. It
> > > seems the "body" hname allows this behaviour.
> >
> > How many mail clients does it work on? And do people even use
> > mailto: links?
> 
> I tried it on mutt, Thunderbird, GMail web and mobile, Outlook web,
> and Samsung's mobile mail app. So it does seem to have wide support.

Thanks for checking.

> If mailto is unused, why would the option and its support be there
> in this project, and also in proprietary clients on mobile and web?

Nobody really knows if it's used or not, or if people opt to use
`git send-email' instead.  But it is currently inexpensive to
support mailto: with headers-only.

> Debbugs also has the behaviour I mentioned, you may try it on any of
> their bug report email pages. For example:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1018118
> (I know it's not exactly an archival project like this.)

Noted.  Yet they also have mailto:$NUM@bugs.debian.org w/o any
args at the top, too.  It really seems like overkill given debbugs
is in the same situation where mail is publicly archived.

> > It would roughly double the the size of HTML
> > responses for /$INBOX/$MSGID/ endpoints and probably increase
> > browser memory use a similar amount.
> 
> That makes sense, thanks.
> 
> While I can't say much about performance in general (I am not much
> familiar with the project internals, and came across this due to
> lore.kernel.org), but regarding browser memory, the threaded view
> already shows multiple messages, so I don't think it would be too
> much of an issue, and the mailto links are apparently only shown
> when you open permalinks.
> 
> I just tried loading on w3m an 896 KB HTML thread from lore.kernel.org
> (containing 2-3 kernel configs, which you'd agree is normally huge
> spam), and w3m seems to take 33MB of memory, a normal amount.

All the HTML generation on the server is already too expensive
for my tastes and I'm always trying to find ways to make it
faster without requiring XS modules nor any AOT compiler.

The /[Tt]/ endpoints are meant to be convenient for downloading
and viewing offline, but yes, they are farily expensive for
browsers.

The permalink endpoints are linked directly from Atom feeds and
may end up being hit more by crawlers.

I also remember the old days when people would be considerate
enough to 'grep ^CONFIG_' to trim down configs before posting.
I don't think that's common, anymore :<

> > Fwiw, I'm not a fan of quoting publicly-archived mail;
> > especially with our "archives first" philosophy.
> > 
> > Quotes makes messages significantly bigger than they need to be;
> > thus more expensive to mirror when the replied message is
> > readily accessible in public archives.  I end up skipping over
> > quotes 99% of the time.
> 
> Isn't quoting when replying to the convention? And most mailing lists
> I have seen use quoting...

Yes, it's from the old Usenet days when NNTP servers would
routinely drop messages during propagation.  Quoting messages
when they miss the archives is fine.  But in the case we're
discussing, messages shown on the web are already archived.

So yes, I believe in evolving the convention towards something
more lightweight to reduce disk/network/memory footprint for
everyone.  But I still follow old conventions when replying to
this message :x

Unfortunately; over-quoting seems more common, and corporations
seem to be pushing the convention towards HTML and top-posting;
or worse: proprietary vendor-locked crap.


Fwiw, the very earliest revisions of public-inbox HTML output
would try to truncate/hide quotes behind another link.  I
eventually decided against it since I wanted to show readers
how wasteful quotes are, so now they're shown in full.

I suspect clients hiding quoted text by default encourages
people to over-quote and waste bandwidth.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Feature request: Support for body in mailto links
  2022-12-22 11:28     ` Eric Wong
@ 2024-11-05 19:49       ` Andrew Cooper
  0 siblings, 0 replies; 5+ messages in thread
From: Andrew Cooper @ 2024-11-05 19:49 UTC (permalink / raw)
  To: e; +Cc: code, meta

Hello,

I'd like to +1 this feature request.

When interacting with a list that you're not subscribed to, the mailto
links are far more convenient than dealing with mboxes.

However, getting the body back to being nicely interleaved is quite a
lot of manual effort.  I also noticed that the Debian bug-tracker gives
a nicely quoted body, and it would be awesome if public-inbox could too.

I'm not sure if I have any useful to add to the size-of-replies argument.

~Andrew

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2024-11-05 19:49 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-12-21 15:21 Feature request: Support for body in mailto links Siddh Raman Pant
2022-12-21 21:04 ` Eric Wong
2022-12-22  6:43   ` Siddh Raman Pant
2022-12-22 11:28     ` Eric Wong
2024-11-05 19:49       ` Andrew Cooper

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).