smarx

Here's an implementation in Python built on top of Redis using sorted sets:

    class TimeStore:
        def __init__(self, redis_client):
            self.redis_client = redis_client

        @staticmethod
        def timestamp(time): return (time-datetime.datetime(1970,1,1)).total_seconds()

        def set_value(self, key, value, time=None):
            if time is None: time = datetime.datetime.utcnow()

            self.redis_client.zadd(key, self.timestamp(time), value)

        def get_value(self, key, time=None):
            if time is None: time = datetime.datetime.utcnow()

            for item in self.redis_client.zrevrangebyscore(key, self.timestamp(time), 0, start=0, num=1):
                return item
            return None

        def cleanup_before(self, key, time):
            self.redis_client.zremrangebyscore(key, 0, self.timestamp(time))

One big issue is that we're just not a good product fit for something heavy, so I would expect most people who want more than what we'll give them for $4.95/month to eventually discover that Webscript is the wrong service for them. (For example, technology-wise, they should be using something that doesn't spin up a new Lua VM on every web request.)

We could certainly adapt Webscript to be a better product for bigger workloads, but that would be a lot of work on our side, and that product might end up just being "Heroku but with Lua," which is probably a bad product. :-)

I also doubt that your experience applies here in terms of those heavy users wanting 2x the use for 4x the price. At 4x the price, Webscript would cost close to $20 per month, and we would start to compete price-wise with shared web hosting or VM hosting solutions. I'm not sure there are really users who want something like Webscript for that price.

Thanks for explaining!

I don't think this is a real issue. For the scenario you're imagining, there would have to be an SMTP relay somewhere that met the following requirements:

1. It doesn't require authentication. (If it required authentication, then there would be no way to gain anonymity.) I think this is extremely rare these days.

2. Other SMTP servers are willing to receive mail from it. This seems unlikely, since such a server is almost certainly going to be used to send a lot of spam.

3. This open relay keeps track of the sender in some weak way (since there's no authentication), like perhaps IP address. (If this weren't the case, there would be no reason to use a third-party service to hide your identity.)

If you could find some SMTP server that met all these requirements, then you would have motivation as a spammer to use a third-party service to hide your IP address. But a VPN would be a better way to do that then using something like Webscript. Webscript will be comparatively slow, we're likely to shut down a spammer because their traffic will be heavier than what we expect/allow, and we don't have a lot of IP addresses, so we would certainly just get blocked at some point just as the spammer would have if they hadn't been using us.

Because we believe that the incremental cost of supporting such customers would exceed the additional revenue it would generate.

(I guess that's a sort of trivial answer? Feel free to ask follow-up questions if you're genuinely curious about it.)

No. The $4.95 plan is the only/largest plan we have.

When someone starts hitting us with a lot of concurrent requests or storing a lot of data, we do sometimes have to ask people to change what they're doing.

I'm glad you like it, but we have no plans to take payments in any other form.

Is there a reason you don't want to use Stripe?

Hi all! I'm one of Webscript's founders.

It's nice to see Webscript back on HN. You may enjoy reading the discussion from a couple years back when we first launched: https://news.ycombinator.com/item?id=4718686.

Hi! I'm one of Webscript's founders.

What do you mean by spammers?

If you're talking about email, Webscript can be made to talk to an SMTP server, but whoever writes the script could presumably have talked directly to that SMTP server instead, and that would have been more efficient. So why would Webscript be used for spamming?

Definitely! Just as a shared hoster is less capable than running your own VM and a cash register is less capable than a laptop. That doesn't mean those things aren't useful. :-)

I'd say that most of the time, people are more productive with more specialized tools if the tool happens to specialize in what they're trying to do.

Hi, Webscript founder here.

Generally, I think our customers fall into two large buckets:

1. Experienced developers who want something lighter-weight than, e.g., Heroku.

2. Inexperienced developers (perhaps even first-time developers) who are trying to do something simple (e.g. send themselves a text message when a webhook fires).

To take your Stripe example, I imagine based on your question that you're thinking about the case where you have a server-side app already, in which case handling Stripe is very little extra work. If you are instead, for example, selling a digital good via a static website, Webscript would be a lot easier than building a full web app. You could have the job done via Webscript by the time you created a new app and set up your git repo for Heroku.

As to the DoS attack angle, do you have an example of how you see Webscript being used for something like that? If you mean flooding some target with HTTP requests, it seems like it would be more efficient for an attacker to send the requests themselves rather than try to funnel them through Webscript.

Regardless of what word comes next, it should probably be "24 x 7 x 52".

Dropbox itself makes this even easier now. See https://www.dropbox.com/developers/blog/94/generate-an-acces....

Of course. :-)

If you're polling client-side for a single account, you should just be using longpoll_delta[1] and delta[2]. But maybe I misunderstood the use case?

[1] https://www.dropbox.com/developers/core/docs#longpoll-delta

[2] https://www.dropbox.com/developers/core/docs#delta

I went ahead and published Python code to generate fake webhook requests. See https://github.com/dropbox/dropbox_hook.

Take a look at https://www.dropbox.com/developers/webhooks/tutorial#best-pr..., specifically the part about managing concurrency.

There are rate limits (per user) on the Dropbox side, but they're pretty high. I think the bigger concurrency issue is going to be on your end (making sure you don't process the same changes multiple times). Taking a lease per-user is a good start, and we're going to publish a more advanced sample in the coming weeks that uses a queue to really eliminate duplicate calls.

Webhooks don't require SSL. We're going to publish a little Python script soon that can generate fake webhook notifications for local testing, but in the meantime, I'd suggest just using curl. Something like this:

curl http://127.0.0.1/whatever -d '{"deltas": {"users:" [12345]}}'

Another possibility is to use a tool like ngrok or localtunnel, which is what some of our beta testers did.

This is mostly what Carousel does. The photos are all stored in Dropbox. What it doesn't do is your #2, which is to automatically delete the photos from your local device after a period of time. You can do this safely yourself, though, since the files are all stored in Dropbox.

I think I'm missing some context, but this probably isn't the right place to figure it out. Ping me on email (smarx@dropbox.com) if you want, though!

The blog post (https://www.dropbox.com/developers/blog/82/dropbox-2048-save...) links to it. Here's the direct link to see your datastores: https://www.dropbox.com/developers/apps/datastores.

You should actually be able to use the full Dropbox API from JavaScript. See https://github.com/dropbox/dropbox-js and https://www.dropbox.com/developers/datastore/docs/js.

One of the big advantages (not really used in this sample) is conflict resolution. With a text file, if you make changes on two different devices while one (or both) is offline, you'd end up with a conflict and two versions of the text file.

With datastores, the changes are automatically merged according to developer-specified conflict resolution rules.

What a strange coincidence! 97% of the Fortune 500 also use Dropbox. :-)

From https://www.dropbox.com/news/company-info: "Dropbox is used in over 4 million businesses with presence in 97 percent of Fortune 500 companies."

You might consider Dropbox, since the Datastore API seems perfect for the persistence (and live syncing) of data. Try the sample task-list app in a couple tabs: https://dl.dropboxusercontent.com/u/182037406/js-datastore-a...

This is incorrect. OT can indeed be implemented on the client.

The way it works in the Datastore API is that the client sends its changes to the server with an attached "parent revision." If that parent revision is the revision that the server has, then the change goes through (no conflict). If the revision doesn't match, then the change is rejected by the server, and it's up to the client to pull down the latest changes from the server, merge things (via, in the case of lists, OT), and then try again.

The main pro is the automatic merging. "The API" is a fuzzy term here. There's an interaction between a client and a server, and the client is running an SDK. In the case of the Datastore API, the server doesn't perform any merging or OT, but the client SDK does. Your code just gets conflict resolution for free. The Python SDK is a bit of a special case in that it doesn't implement this logic, but the others (JavaScript, iOS, Android) do.

In contrast, if you make a change to a sqlite database on two different devices, you now have two different files and no way to merge them. (There are people who have used Dropbox to sync sqlite databases this way, and they've ended up writing diff/patch over sqlite to merge changes. Using datastores is a lot simpler and more likely to be correct.)

Oh, I misunderstood "very large." :-) The actual code sample has a more detailed list of exceptions that it handles, but the code was a bit long.

Hi, I wrote the tutorial. :-)

In general, I based the tutorial on the sample app that ships with the SDK. That app uses Flask and presents some actual UI. If you want full working code, I would suggest taking a look at that sample.

The tutorial is basically fragments from that sample that show the basic concepts, but without some boilerplate, the fragments are not themselves runnable.

(BTW, where are the "very large except clauses?")