JPL Horizons Sending Too Many Emails | Hacker News Reader

JPL Horizons Sending Too Many Emails

astronomy.stackexchange.com

83 pointsazeemba15 comments

It's funny how small some communities are, particularly the ones rallied around niche tools or capabilities.

> If [it's any] consolation, about 150K messages were received here from your system explaining it can't deliver X for the last four hours, but it will keep trying for the next five days, each with a copy of the as-yet undelivered email.

I find this a tricky thing to look out for. In unusual situations you want good logs, but you don't want to the logs to be the problem themselves.

This reminds me too much of all the procmail and m4 scripts I wrote at an astrophysics lab about 20 years ago.

Better days now, better days.

If email had an ability to delete a message after you've sent it like every other chat platform this wouldn't have been a big issue. Unfortunately the email protocol seems to be stuck and is unable to evolve with the needs of the current times.

Here I'm thinking that sending an email to get data back like this an odd choice compared to something like an API sending back JSON or XML or anything other than a friggin email.

I'm pretty sure this API doesn't run synchronously. You're not going to sit with a request open for hours (days?) waiting for the server to return data to you.

Email is maybe not ideal, but a lot of the other ways of returning results from an API asynchronously require clients to set up their own infrastructure (or pay to use someone else's), which might not be desirable for this particular API's users.

Nonetheless, it is a bit surprising that a single query results in 100 emails. It seems to send one email for each object observed, rather than a single email informing the user that their job has finished.

It’s really a great solution in a long-running job situation, the more I think about it. Especially on your point about setting up infrastructure. Email, in this case, is effectively a webhook handler for their results. Doesn’t require the end user to maintain the endpoint though, and can leverage the existing redelivery attempts, etc. May not be the “coolest” - but leverages decades of accumulated knowledge and reusable solutions.

No thanks, I'm fine not letting people reach into my inbox to delete things.

Agreed. Once you start post-send changes for remote deletion then there could be further modifications to the spec by less than benevolent marketing tech companies for dynamic email. A/b testing facts. Workshopping layouts or grammar sentiment to see if you’ll click a link. Like some dumb video streaming homepage.

Keep email the same a printing to paper. One improvement would be encryption over wire but what can you do.

Are you at all familiar with 'the email protocol'? I've read enough to implement a client and relay, and I can't imagine what that would look like. Email certainly continues to develop (e.g. BIMI) but that doesn't mean you can bolt on anything; deletion seems fundamentally not possible without an overhaul such that it would be an unrecognisable system. Standardising 'deletion requests' (such as Outlook has a proprietary version of I think?), but is there any point? Is it worth the confusion from users who would reasonably expect that deletion means deletion, not ~hide, and even that only if the receiving client is up to date with latest spec and does implement it?

>but is there any point?

So you don't have to see emails that people have accidently sent or have sent with a typo they later corrected. This situation in this article could have been cleaned up by the party who made the mess instead of having to employ an O(n) soliton of asking every single person they messaged to clean up their mess.

which chat platform/client deletes their messages? the ones i use, don't. IRC is the only one that i know of that doesn't permanently store messages, and some only store messages in the client but not the server.

Skype, Discord, Slack, WhatsApp, Telegram, etc. It's hard to think of one that doesn't let you since it's a universal feature.

i think i misread your previous comment. you are talking about the ability for the sender to delete a message from the recipient. my bad.

there are a few that don't have that feature, or a limited version of it. (this is meant purely to be informative for the curious, not as an argument against your point)

wechat allows to retract a message for two minutes after it has been sent. a notification that a message has been retracted remains behind. so that is not a missing feature but intentional.

deltachat doesn't support retraction but it has a feature to automatically delete messages after a certain time, which has to be activated before the messages are sent.

IRC of course because its messages are not permanent to begin with. each client just has a log of the messages received that they are free to use as they see fit.

and i suppose any trivial chat feature, like that in jitsi, well, i suppose because they are simple implementations and not serious messaging.

of these wechat is the most interesting because they made a deliberate choice not to allow retraction except for a very short window.

Reply on news.ycombinator.com