21–30 of 39 posts
Earlier quoted context omitted.
But... SMTP stands for SIMPLE Mail Transfer Protocol.
Depends on what you are comparing it to. LDAP stands for Lightweight Directory Access Protocol. I don't think that anyone would consider LDAP lightweight, but compared to X.509...
In terms of managing IMAP connections, async is definitely the way to go. For our product, lightermail.com, I ported Python's imaplib to run on Tornado's ioloop (adding a few features like IDLE support and command pipelining). Not only can you manage a lot of connections with little memory, but you can do some really cool things (like the pipelining of commands mentioned above) that are unavailable to regular synchro…
Also, not sure if it makes sense for your use case, but I considered moving to Postmark's Inbound API (http://postmarkapp.com/inbound). May work well for some people.
Telnet clients are also fun. I haven't written an http client, but looking at the state of web programming, I imagine that is a whole nother can of worms. I think I'd rather go for a root canal.
Building an email client is one of those fun projects you can play with and learn a lot about how the internet works at the same time. Like most cool projects, you can either stop with a little functionality or keep going into all kinds of other stuff. Telnet clients are also fun. I haven't written an http client, but looking at the state of web programming, I imagine that is a whole nother can of worms. I think I'd…
In terms of managing IMAP connections, async is definitely the way to go. For our product, lightermail.com, I ported Python's imaplib to run on Tornado's ioloop (adding a few features like IDLE support and command pipelining). Not only can you manage a lot of connections with little memory, but you can do some really cool things (like the pipelining of commands mentioned above) that are unavailable to regular synchro…
Sounds awesome. Just yesterday I was trying to hack pipelining support into imaplib, ultimately for use with Tornado. I'd be very interested in your implementation.
Whatever you do when you build your client, do me one UI favor: Reverse the fields when composing. Body, then subject, then addressees, then the Send button. Think of all the headaches due to accidentally-sent mails the world over.
[Disclaimer: I'm a co-founder]
Building an email client is one of those fun projects you can play with and learn a lot about how the internet works at the same time. Like most cool projects, you can either stop with a little functionality or keep going into all kinds of other stuff. Telnet clients are also fun. I haven't written an http client, but looking at the state of web programming, I imagine that is a whole nother can of worms. I think I'd…
Earlier quoted context omitted.
No, please don't, here is one voice against "let's do it totally different for idiots". Next you want to have 3 confirmation dialogs "do you really want to send" followed by "did you prove-read your mail again?" followed by "you clicked YES too fast, go back to start and prove-read again". Also, worst thing you actually can do is to put the save/send/ok button on the bottom when all other UI elements are on the top o…
I don't think slippery-slope is an appropriate argument to make here, or really anywhere. To answer the UI elements on the bottom, I'm not sure I actually press the Send button at all, instead opting for a keystroke depending on the client. The physical analogue I base my request off is the order I fill out a letter or card--I write my message, then I sign it, and then I seal and address the envelope. Beside that, wh…
Second i bet you that most people find the send button easier when it's somewhere they expect. Where the other buttons are.
Third, physical analog bla bla, really... Nobody thinks "hey i am writing an e-mail, that's just like real mail, EXCEPT i write on a keyboard, look on a screen and everything else i touch and see is not a physical letter or pen or paper at all!". The real-world vs virtual-world comparison makes most sense for icons and such, in my oppinion. Not so much for workflows. You also don't ask people to walk to a virtual post box to send the letter. Or let them "stamp" it. Or as you said yourself, to sign it or to seal it.
Nothing keeps one from putting ALL controls to the bottom, a good interface may even accomplish that nicely. Except that it's only there to annoy people, restrain adoption and giving users a hard time figuring that out. You may be able to quickly learn that, i may be able to do that. My mother or grandmother? Not so much.
It'd be very interesting to see some A/B testing on this. Maybe i'm wrong, who knows.
Earlier quoted context omitted.
Depends on what you are comparing it to. LDAP stands for Lightweight Directory Access Protocol. I don't think that anyone would consider LDAP lightweight, but compared to X.509...
There's also Simple Object Access Protocol.