bct

getmail, fetchmail, etc.

It's a matter of resources. It was a very ambitious project, and they didn't have the funding behind it that Apple and Google do.

A boycott isn't made up out of individuals. Doing this is a waste of your effort unless it's part of a focussed campaign.

No.

You're not listening, and you're not arguing in good faith.

> involves being told how to construct a URI

The crucial thing that you're missing is that it's being told how to construct that URI in-band. Not in a piece of documentation that has to be hard-coded into the client.

We're talking about two totally different kinds of problems.

You're talking about wire formats and structures that feel natural to use for particular kinds of calculations. I'm talking about recognizing properties that we might need a particular system to have (ease of use being only one of them), and ensuring them.

The line I quoted tells us exactly which problems (in the sense that I'm talking about) REST is suited for: the ones where those benefits are needed (and where the tradeoffs aren't to costly).

> what resource is it acting on?

The distance between the two cities.

> You have to come up with some added, unnecessary, implementation-exposing abstraction like "CityPair".

This is a really weird thing to say. No, you don't. I have no idea why you would think that.

> What are the four CRUD operations for it? [...] In which case "delete" could be ill-defined

Not every method has to be valid for every resource. It's a total non-issue that you can't delete a distance.

(And POST/GET/PUT/DELETE is a very different concept from CRUD.)

No, the problem space being "scalability of component interactions, generality of interfaces, independent deployment of components, and intermediary components".

This merely happens to overlap significantly with the requirements of public APIs.

I have difficulty imagining your distance calculator needing any of those things, though.

> 1. [send a link for each possible combination]

> 2. instruct clients on how to construct appropriate URIs

> 3. link a URI for the starting city and then from there link them to possible choices of the second city

All three of these are possible RESTful solutions, and I can imagine situations where each of them might make sense.

But what you're probably looking for is something like this:

  <form><select name="city1">...</select><select name="city2">...</select></form>

(Using URL templates is a potentially simpler way to achieve the same thing). This is, of course, your solution 2.

There are tradeoffs involved in using this style. Are they worth it? That really depends on the larger system and all kinds of details which you've left out.

The thesis lays out in detail what REST provides:

"REST provides a set of architectural constraints that, when applied as a whole, emphasizes scalability of component interactions, generality of interfaces, independent deployment of components, and intermediary components to reduce interaction latency, enforce security, and encapsulate legacy systems."

The existence of these properties should be fairly evident when you examine the constraints.

I think large part of the confusion comes from not recognizing the difference between "Any system can be built in a RESTful style" (this is true) and "Every system should be built in a RESTful style" (this is a straw man).

No, he makes it quite clear that it's a solution designed for a particular problem space. You're debating a straw man.

Nobody ever said that you should use REST if it doesn't suit the problem you're trying to solve.

APIs that ignore the realities of distributed computing and that each have different special-snowflake wire formats requiring tedious documentation: the worst of both worlds.

> Making a call to a server should be like calling a function anywhere else

You can make calling a function on a remote machine look and seem (superficially) like calling a local function, but they will never have similar behaviour. A network is very different from a motherboard.

http://www.tbray.org/ongoing/When/200x/2009/05/25/HTTP-and-t...

It's worse than that, because sheep don't walk around randomly; they follow repetitive, collectively-defined paths, like most herd animals.

Ha.

> People, you are some of the brightest and cleverest people walking the earth.

Oh, please. It's exactly this kind of self-congratulatory bullshit that produces this community's inch-deep intellectual culture.

If you can bring in toads to eat a significant fraction of the beetles that are destroying the sugar cane crops, why wouldn't you do that?

(Because: http://en.wikipedia.org/wiki/Cane_toads_in_Australia . These are complex, poorly understood systems, and the results will almost certainly not be what you expected. This isn't engineering.)

"The works of the roots of the vines, of the trees, must be destroyed to keep up the price, and this is the saddest, bitterest thing of all. Carloads of oranges dumped on the ground. The people came for miles to take the fruit, but this could not be. How would they buy oranges at twenty cents a dozen if they could drive out and pick them up? And men with hoses squirt kerosene on the oranges, and they are angry at the crime, angry at the people who have come to take the fruit. A million people hungry, needing the fruit- and kerosene sprayed over the golden mountains. And the smell of rot fills the country."

rm -rf doesn't follow symlinks:

    /tmp $ mkdir -p a/b/c
    /tmp $ mkdir -p a/d/e
    /tmp $ cd a/b/c
    /tmp/a/b/c $ ln -s /tmp/a/d .
    /tmp/a/b/c $ cd ../../
    /tmp/a $ ls */*
    b/c:
    d

    d/e:
    /tmp/a $ rm -rf b
    /tmp/a $ ls
    d

It would be pretty stupid for it to.

The secret to understanding HN is that it's not actually a site for hackers. The word "Hacker" in the title bar is written on a board that was nailed up over the word "Startup".

I never said anything about success.

We don't need to inject discrimination and close-mindedness, but we do need to counteract it. That means we can't just passively "be open".

> she has nothing to do with the rest of her group.

You're wrong. There are lots of things that women experience that men do not (and vice-versa).

> they need only be open to everyone

The word "only" makes this sentence completely wrong.

In startup terms it's like saying that to make a successful product you need only make something useful and put up a web page offering it for sale. It would be great if it was that simple!

> Therefore, it follows that per capita, it's going to be harder to bring women into the fold.

That doesn't follow at all. It could be that the industry has some kind of blind spot that could be easily addressed by e.g. encouraging and welcoming people who are interested but generally left out.

Oh, you're saying that this isn't respectful of him. I thought you were saying that he is not deserving of respect.

I'm supposed to dislike an incredibly prolific and inspiring guy because he took some stuff offline?

It's useful in some contexts but overly broad in others. The differences between a boat and a stapler are readily apparent; the differences between a copyright and a patent, much less so. Imprecise language takes advantage of that.

Yes, I used /dev/null.

You really think candidates are (or could be) chosen based on anything even remotely related to those abilities?