Understand that I make this suggestion with the greatest respect...
If you really want this product to be successful, you need to provide *detailed* error messages.
I worked for days to figure out why I was getting "The remote endpoint could not be called, or the response it returned was invalid." message. I couldn't tell if a connection to my HTTPS end-point had been made (although I could tell this at my server). I did see from a network trace that the SSL handshake had been successful (had to get out the network sniffer to do this), but following that, the Service Simulator closed the connection, cleanly, with no SSL level errors reported. After a *bunch* of sleuthing I finally decided that the connection was being closed because the SSL code on your side, the post-connection-callback (in OpenSSL parlance) discovered something it didn't like in the certificate, and terminated the session, before it got to request/response processing. It turns out that the X.509 commonName didn't match the Fully Qualified Domain Name in the subject_alternate_names section of the .cnf file. My bad. However, having coded similar callbacks for other SSL connections, I *know* that your code determined *exactly* what the issue was. However, all that was reported was the generic message.
Further, with a poorly "crafted" response sent back to the simulator I simply see a message telling me the response is invalid. OK, fine it is, but your simulator *could* tell me where in the response it encountered (the first) error.
Long story shorter (maybe), I've developed software for more than 3 decades and I *know* that for a piece of code to actually be a product, it needs detailed error messages. It's a basic requirement for an actual product. I do this with every piece of code I develop, even stuff that's just for my own use. I know, in college we were just trying to knock a piece of code together that the prof. will accept, with no intent of other people using it, or it being reused. This breeds a very bad habit.
Having released a lot of code in my time, it's very gratifying when users tell me they just picked up the code/utility that perhaps didn't work right out of the box, but the messages led them quickly to the solution (it's amazing how often the exact solution to an error message can be suggested). It feels good when people tell you this... trust me. You and the product get a good reputation.
I have no doubt that implementing detailed error messages is a lot LESS work than you think, and the benefit is a lot LESS of your time spent doing mindless support (managers take note!!), not to mention saving developers like me a bunch of time. IMHO, a piece of code is just a hack if it doesn't do detailed messaging.
One last thing, I work with a lot of open source code, and it generally works a lot better than what I've seen from the Alexa tools. Better documented, more robust (vs. "robusted") and easy to debug/diagnose. Please make the effort to improve your tools, it'll help *you* and *me*.
Thanks for listening and have a nice day,
Eric
