JPL Horizons Sending Too Many Emails

https://astronomy.stackexchange.com/questions/53617/jpl-horizons-sending-too-many-emails

by azeemba • 3 years ago

83 15 3 years ago

astronomy.stackexchange.com

alhirzel• 3 years ago

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

CoolGuySteve• 3 years ago

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.

charcircuit3• 3 years ago

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.

dylan604• 3 years ago

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.

kelnos2• 3 years ago

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.

kelnos2• 3 years ago

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

ok_computer• 3 years ago

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.

OJFord• 3 years ago

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?

charcircuit3• 3 years ago

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.

em-bee2• 3 years ago

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.

charcircuit3• 3 years ago

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

iudqnolq• 3 years ago

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.

JPL Horizons Sending Too Many Emails

Related Stories