< ^ txt
Fri Mar 10 07:37:03 EST 2017
Slept from ten-thirty to five-thirty.
Windy, partly sunny, and a high of twenty-eight today.
Read a chapter of Three Musketeers after I woke up.
Work:
- Finish bag backups
It's complicated.
Fifteen minute walk at lunch.
Sunny, but a biting wind.
Home:
- Golang or Faux Bat stuff
Done.
Local mail get stored in mbox files (`/var/spool/mail/myuser` or `/var/mail/myuser`).
All messages get stored in one file, so some type of file locking is necessary.
OpenBSD has LOCKSPOOL(1).
Debian has EXIM_LOCK(8).
On FreeBSD, see MBOX(5), which discusses locking.
Rather than screwing around with mbox files, I'd rather attack this at the sendmail binary.
Can we improve on ssmtp?
https://wiki.archlinux.org/index.php/SSMTP
http PUT POST idempotent
http://stackoverflow.com/questions/630453/put-vs-post-in-rest
> PUT replaces the resource at the known url if it already exists, so sending the same request twice has no effect. In other words, calls to PUT are idempotent.
> Or from the other side of the fence: PUT if the client determines the resulting resource's address, POST if the server does it.
> I'd like to add my "pragmatic" advice. Use PUT when you know the "id" by which the object you are saving can be retrieved. Using PUT won't work too well if you need, say, a database generated id to be returned for you to do future lookups or updates.
Say we have a list app, for example.
When adding a new list item, we won't necessarily know the id/url the server will give the particular item, so we use POST against the general "additem" url or whatever.
If we're updating an existing list item at a known url, we us PUT.
https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
So, if we're sending messages, we're generally going to use POST.
Ended up working on some D&D stuff.
Watched a few episodes of Star vs the Forces of Evil.
Breakfast: carrots, yogurt, coffee
Lunch: nuts
Dinner: Tubby's
< ^ txt