3 ms·

That would be fun stuff when requesting a web address having to wait for the batch review! That would indeed be a return to the analog world.

pavlov 2y ago
I'd like to have a Slack bot that explains this situation: "Thanks for contacting pavlov. Due to operating system limits, his reply to your message won't be published until 3pm tomorrow. Your patience is appreciated." Would be a stress antidote.
- rbanffy 2y ago
  Pluto will be prime real-estate for the people who don’t like interruptions.
jandrese 2y ago
Several years ago I worked on a system that operated quite like this. It used DTN (Delay/Disruption Tolerant Networking) and web proxies to allow really remote villages to get internet by bus or mule drawn carriage or however they got supplies. You would make the request, it would be batched up with all of the other requests and handed off to he supply vehicle that came around every week or twice a week. That vehicle would eventually make it to a bigger city where they had real internet and it would spider out the requests a few layers deep (up to a low number of MB), then the vehicle would make another trek and it would populate a web cache in the villages so someone hitting the same URL would be served a slightly stale version of the content. It also had email so the person who make the request would get a mail stating that it was ready and give them the link.
- rietta 2y ago
  Was this ever actually used in real life or was it an experiment only?
  - jandrese 2y ago
    We handed it off to people who were supposed to deploy it, but I had to move on after that so I never got to see it live. I kind of suspect that the window of usefulness was very short since cell towers were springing up even in really remote areas and they'd be a thousand times more useful even with just GPRS level connectivity.
- gary_0 2y ago
  This reminds me of back when e-mail clients would store your outgoing e-mails in the "outbox" waiting for the next time you dialed in. Nowadays networked software (and much of society) can't handle days of latency, only milliseconds, and I'm not sure that's a good thing.
  - rbanffy 2y ago
    This will be one of the upsides of living on Mars.
  - canucker2016 2y ago
    Not just for dialup network access. Microsoft Mail for PC Networks used two processes - one for the email client and one for sending/receiving email (aka the "email pump") . Since Windows 3.x used co-operative multitasking, only one process could run at a time, the email pump detected idle time and start sending/receiving email. Until that processing email time, the user could open the outbox and open outgoing emails, and modify and resend or cancel them. A few years pass and Exchange 4.0 is about to ship. But now the second process has been eliminated and emails are sent via RPC to the Exchange server. The user, though, has almost no chance to stop an email from being sent since the email spends almost no time in the outbox before the Exchange server sees and processes the outgoing email. People actually grumbled about Exchange being too fast. I took a look through the list of email message properties supported in Extended MAPI. One of them was a "time delay before sending" scalar, measured in seconds. The Exchange email client (as seen in Win95, also supported on Win3.x and NT) supported extension DLLs. I created an extension DLL that let the user specify a time delay for outgoing emails, and listened for an "email send" notification and then set the user-specified "time delay before sending" property on the outgoing email. Now outgoing emails would sit in the outbox for the user-specified amount of time before the Exchange server would process them. Problem solved. AFAIK the extension DLL was the only code that had set the "time delay before sending" property on emails. It worked the first time I ran the code. Someone did the appropriate testing. Eventually Outlook 97 shipped. The extension still worked. But a later Outlook update broke the extension DLL. Finally Outlook added support for the "time delay before sending" property for outgoing emails - no need for an extension DLL anymore.
kalleboo 2y ago
Stallman uses an email script to read the web https://stallman.org/stallman-computing.html#:~:text=I%20generally%20do%20not%20connect,mails%20them%20back%20to%20me https://stallman.org/stallman-computing.html#:~:text=I%20gen....

pavlov 2y ago

I'd like to have a Slack bot that explains this situation: "Thanks for contacting pavlov. Due to operating system limits, his reply to your message won't be published until 3pm tomorrow. Your patience is appreciated." Would be a stress antidote.

rbanffy 2y ago
Pluto will be prime real-estate for the people who don’t like interruptions.

jandrese 2y ago

Several years ago I worked on a system that operated quite like this. It used DTN (Delay/Disruption Tolerant Networking) and web proxies to allow really remote villages to get internet by bus or mule drawn carriage or however they got supplies. You would make the request, it would be batched up with all of the other requests and handed off to he supply vehicle that came around every week or twice a week. That vehicle would eventually make it to a bigger city where they had real internet and it would spider out the requests a few layers deep (up to a low number of MB), then the vehicle would make another trek and it would populate a web cache in the villages so someone hitting the same URL would be served a slightly stale version of the content. It also had email so the person who make the request would get a mail stating that it was ready and give them the link.

rietta 2y ago
Was this ever actually used in real life or was it an experiment only?
- jandrese 2y ago
  We handed it off to people who were supposed to deploy it, but I had to move on after that so I never got to see it live. I kind of suspect that the window of usefulness was very short since cell towers were springing up even in really remote areas and they'd be a thousand times more useful even with just GPRS level connectivity.
gary_0 2y ago
This reminds me of back when e-mail clients would store your outgoing e-mails in the "outbox" waiting for the next time you dialed in. Nowadays networked software (and much of society) can't handle days of latency, only milliseconds, and I'm not sure that's a good thing.
- rbanffy 2y ago
  This will be one of the upsides of living on Mars.
- canucker2016 2y ago
  Not just for dialup network access. Microsoft Mail for PC Networks used two processes - one for the email client and one for sending/receiving email (aka the "email pump") . Since Windows 3.x used co-operative multitasking, only one process could run at a time, the email pump detected idle time and start sending/receiving email. Until that processing email time, the user could open the outbox and open outgoing emails, and modify and resend or cancel them. A few years pass and Exchange 4.0 is about to ship. But now the second process has been eliminated and emails are sent via RPC to the Exchange server. The user, though, has almost no chance to stop an email from being sent since the email spends almost no time in the outbox before the Exchange server sees and processes the outgoing email. People actually grumbled about Exchange being too fast. I took a look through the list of email message properties supported in Extended MAPI. One of them was a "time delay before sending" scalar, measured in seconds. The Exchange email client (as seen in Win95, also supported on Win3.x and NT) supported extension DLLs. I created an extension DLL that let the user specify a time delay for outgoing emails, and listened for an "email send" notification and then set the user-specified "time delay before sending" property on the outgoing email. Now outgoing emails would sit in the outbox for the user-specified amount of time before the Exchange server would process them. Problem solved. AFAIK the extension DLL was the only code that had set the "time delay before sending" property on emails. It worked the first time I ran the code. Someone did the appropriate testing. Eventually Outlook 97 shipped. The extension still worked. But a later Outlook update broke the extension DLL. Finally Outlook added support for the "time delay before sending" property for outgoing emails - no need for an extension DLL anymore.

kalleboo 2y ago

Stallman uses an email script to read the web https://stallman.org/stallman-computing.html#:~:text=I%20generally%20do%20not%20connect,mails%20them%20back%20to%20me https://stallman.org/stallman-computing.html#:~:text=I%20gen....