All right, my mistake, Outlook DOES have it! And it seems to be well hidden because I can’t find it. Either way, whatever mail client is used in Haiku ought to have this possibility as well.
That’s all I want. I prefer “ownership” of our codebase in any case, simply because we have a centralised, SVN-like working style that’s ill-suited to the GitHub fork-and-pull method.
But the sources are out there just in case something turns out to be useful for OS-level stuff. In the meantime we’ll work on a proper Haiku e-Mail client (whether this takes the form of glue or a monolith is still up in the air). I’d prefer (naturally) that it get included in the release, because I feel like Haiku should include a full distribution of software out of the box, and what it has right now is neither a monolithic eMail client nor a lightweight one, just the parts to build either or both.
Well, here’s how I see it. Eudora has a very dedicated following of users on Windows. QUALCOMM did 50% of the work on it, and I feel like I’d be doing the Eudora community a disservice if I didn’t at least try to assemble the best team possible and do the other 50%, in spite of the fact that we have to work around the API rather than with it. On the other hand, Haiku’s API seems to be literally BUILT for this kind of application, but there’s zero fan-following and we’d have to do 100% of the work.
Yet the 100% of work we’d have to do on Haiku is less, in an absolute rather than relative sense, than the 50% of work we have to do on Windows.
1 Like
How does the future-send function works?
Do the client doest the timing or the server in this case?
Client. It’s an “on-or-after” thing. In other words, if you shut down your computer, it won’t send the future message while it’s shut down; it’ll take the next opportunity (i.e. when the client is started again).
Yes, Outlook the same way. To access it, while composing a message choose Options / Delay Delivery. Shorthand for this is (ALT) P D.
Then it is absolutely irrelevant. Sorry.
If i want someting get sent in a defined time, it should be sent. No but and no if.
The protocol doesnt let me?
Then the protocol is wrong.
Dont provide something, what you cant guarante.
1 Like
It is a limitation; it is advertised that way. Do not deliver before xxx date/time. And if you just leave your email program running, it does get mailed. It might be just the thing for the poster’s use case mentioned earlier, where a message needed to go at midnight, and he’d be sleeping.
And what if i think, ok it will be sent, so i can shut my computer down, and go to make errands around the world?
2 Likes
Uhm, you won’t do it but once?
I do errands around the world.
1 Like
Perhaps it should store this in a 24/7 server and send a WOL signal to the box that the mail is stored on so it can send it and shut back down?
@extrowerk I understand. I only meant that if the user used the feature without testing it first, he would learn and not try to use it that way again.
Why is it allowed or considered a good practice in software developement that the user should learn to never trust any software/function trough burning his fingers?
The idea with WOL is for me absolutely nonsense. Just try to send a WOL signal to my laptop, switched off, in my backpack in the luggage container on the airplane.
If a server runs 24/7 and able to WOL my laptop, it can even send my mail, right?
@extrowerk I cannot speak for Microsoft programming staff or why they designed the feature to be client-side. The feature has been in place since at least Outlook 2003 and I believe it is documented that delayed sending will only happen while the client is running.
Not a bad idea on having a computer up and running to do your offline tasks including mail sending. In this case your procedures for delayed mail would be:
- Connect-in with VNC or RDP to your home based computer
- Send the delayed email but do not exit the mail client
- Disconnect, power down laptop
- Board the plane
All best
…Monty.
Thanks Monty for explaining, how it works and even giving me a workaround. Nice!
I just wanted to point out because this limitation i consider this feature as a “weapon-grade” silliness.
Or become frustrated and angry. YMMV, of course.
I think the reason it was implemented client side is that server side would likely require an RFC on the protocols.
1 Like
This right here is a problem. My hair is going grey from the number of times I’ve received a message saying, “trying to do such-and-such a thing, MFC barfs, tried it again in a different way, MFC still barfs”. I feel like half our time is spent doing dirty hacks and workarounds instead of The Right Thing.
Now, I can’t say Haiku is perfect from a programming standpoint, because it isn’t, but I can’t stand the fact that we’re fighting the Windows API, and meanwhile deadlines are slipping and Eudora’s extremely devout user community is holding my feet to the fire. Isn’t an API supposed to help the programmer? Some help! I want to see what “hindrance” is like!
Only, Qualcomm did it in 1997 (granted, they had a proprietary toolkit to help them, but that toolkit is a pile of horse manure compared to TO-DAY’s MFC). So I feel like I’m making bull$#!+ excuses while Rome’s burning and I’m holding a Zippo in my hand.
Shall I bring out the asbestos violin?