HN user

dropfrog

57 karma
Posts9
Comments8
View on HN

That's exactly what happened - makes me smile. And that someone also received their customized shirts (if all went as planned) because I noticed the shirts had a local company name imprinted. I gave the box with the shirts back to UPS, let them know what had gone down, and hopefully they took care of business.

But that call-in "customer support" is a deal killer. I made an online purchase, a cheap antenna (thank goodness). It arrived in a box with my address taped on it but with customized shirts inside. Boxes were damaged during shipping and when put back together, someone got my stuff and I got theirs. UPS - "it's not on us, contact Best Buy". So I decided to use this to test Best Buy's customer support. I call. Foreign accent. I explain very carefully, slowly, in detail. She didn't listen to a thing I said. Started asking questions that did not pertain to the situation whatsoever. More explanation. 10 minutes in. 15 minutes. Finally she says, oh, I have a tracking number right here and your new shipment is on its way! I said, give me the tracking number, a little surprised she found the solution so suddenly. She read it off. It was the identical tracking number of the damaged box I had just received, and UPS showed it delivered to my house already of course (the one with the shirts inside). Anything to get me off the line. I called her bluff and said "That's the same tracking number as the box that was already delivered and had shirts inside". She said "Well, it's not our responsibility anyway." Me, "goodbye". Only $15 (and 20 minutes of time) to determine to what extent Best Buy cares about customer support, and to guide my purchasing decisions accordingly.

Hacker News users - use the following sandbox login credentials: server=mercury token=hnews. Everyone using these login credentials will be connected to the same cloud repository, 1000 concurrent users max, so don't take a snapshot of anything you don't want the world to see. Thanks and have fun.

Mobile device connections work well enough -- a reliable VOIP app on Android was constructed with the DropFrog service on the backend. Generally, a network connection can get dropped on any device even for a "server" device; it is a failure case to anticipate and program accordingly. On DropFrog, by the way, the channel continues to exist if there are any participants and also for half a minute with no participants whatsoever, anticipating and accommodating failure cases. For the browser (and more) consideration, WebSockets under control of the application programmer makes the most sense, fulfilling the requirements of a persistent and secure connection (WSS). WebSocket support will be added in the future.

Thanks for the feedback. This is a great community. I would love to have more examples on the site. I have included a fully functional Java client on the code page, and will be looking at Objective-C/Swift as well as your suggestion for JavaScript. Asynchronous-response-capable and HTTPS is the basic requirement...if the XHR works I will post the examples on the site.

Regarding comparisons, the DropFrog emphasis is ephemeral messaging--the API is all about communication/messaging between the connected clients and when there are no more channel participants, the channel is destroyed. I have also toyed with the idea of adding limited persistent storage capability; will be listening to feedback.

The pricing is rock bottom, but designed to be sustainable with the current feature set.