This is very important to coordinate systems used to map the height of the ground, because the idea of quantified ‘height’ implies that there is a level surface somewhere below us which has zero height. Even statements about relative height imply extended level surfaces. When we casually say ‘Point A is higher than point B’, what we really mean is ‘The level surface passing through point A, if extended, would pass above point B’ So to accurately quantify the height difference between A and B, we would need to know the shape of the level surface passing through point A. In fact we choose a general ‘reference level surface’ of zero height covering the whole country to which we can refer all our measured heights. This reference level surface is not flat!

— A guide to coordinate systems in Great Britain

I used to think that geo was Hard. But it turns out to be even worse than that.

[Sam] Spade is a thoroughly modern man, fluent in all methods of modern communication, travel, and exchange. He moves around the city with ease using taxi cabs. He frequently communicates with his secretary and other characters via phone booths, organising his and their tasks and travel arrangements to maximise his chances of obtaining the falcon. When he finally gets his hands on it, he stashes it in a baggage claim terminal, and rather than keeping the ticket on his person he posts it to a remote mailbox that he has access to.

[..]

[Spade] successfully navigates the labyrinth of San Francisco – a complex, interconnected place – and is not only unfazed by the systems he is forced to interact with, but makes them an extension of his own abilities and exploits them to his advantage.

Found in the middle of "The City By The Bay" a piece otherwise about the use of stealth in computer games, and how it allows for a more complex type of world than the more normal "shoot people in the face" approach.

Anyway, it seems that Jason Bourne was not the first.

I'm late on this. But from All Things D last week:

[..] soon, apps that use address book data will require explicit user permission to do so.

This doesn't fix the Thing That Actually Happened, it's just a sop to people who want to see more gratuitous security. Merely gating access to the Address book doesn't distinguish properly between Path's "We're going to send your entire address book to our servers and store it forever" friend finder, and Marco's "I just want to make sure a particular contact isn't already in your address book, and wouldn't dream of sending anything to my server" Read Later contact install process. Even post-fix, the Path blog post doesn't make it clear if they're still going to store my address book (assuming I send it to them again) for all time or not, or how much contact information they're sending.

This fix might even make things worse. The new version of Path shows a dialog box explaining roughly what they're going to do with your data before requesting address book access. Once Apple have a gate in the way, are they going to put up two redundant dialog boxes? Or will they drop the helpful one and leave up a single "Path wants access to your address book but I won't tell you why" confirmation?

It's not access to the data that needs guarding. It's what the apps do with the data. Of course, a technical solution to this problem is probably impossible. I'm just bitching.

via Gruber,

Samsung to Merge Bada With Intel-Backed Tizen:

“We have an effort that will merge Bada and Tizen,” a Samsung spokesman confirmed.

Tizen (from the same article):

In September [2011] two Linux software groups, one backed by Samsung, and another by Intel, agreed to jointly develop Tizen, a new operating system for cellphones and other devices, by merging their LiMo and Meego platforms [..]

MeeGo (from wikipedia):

[..] announced at Mobile World Congress in February 2010 by Intel and Nokia in a joint press conference. The stated aim is to merge the efforts of Intel's Moblin and Nokia's Maemo former projects into one new common project.

I really don't see how it can fail.

It absolutely does make it "gamey," which is actually kind of
brilliant. It plays very well to some of the game's core conceits
regarding augmentation in that, if you "upgrade" yourself in this way,
you're no longer connecting with other human beings; you're looking at
readouts and emitting pheromones like some sort of malicious robot air
freshener. The readouts distract you and you may even become dependent
on them, losing all interest in actually engaging with the NPCs you're
verbally sparring with and what motivates them. The augmentation
tricks you into behaving as a machine rather than as a human being. I
watched my roommate fall into exactly this on his first playthrough,
while I didn't take it (I didn't "fail" any conversations, and only
came across one instance where it was clear the aug would've opened up
unavailable avenues of discussion), and it even came back to bite him
(in a way that was, for me as an observer, highly satisfying).

In this respect, the CASIE aug is a surprisingly subversive piece
of game design, and arguably the most convincing piece of in-game
evidence that Humanity Front might be right about a few things.

– JobeGDG

I wrote a thing about what is and isn't REST. That was (what I believe are) the facts. This bit is opinion.

Things that actually matter:

• You've shipped something.
• Your API has client libraries, even if they're trivial wrappers (because people will complain otherwise, or write bad ones).

REST is a nice dream. But I'm not personally a fan. RPC is how programmers' minds work, is the problem. Call method, receive bacon.

Here are some top-of-the head problems with a pure REST API:

• Result pagination - suppose /books/ returns 1 million books? How do I know how many there are? Maybe it returns a list of pages? Suppose there a million pages? Does it merely return the first page and a link to the next one? How do I get page 100? Stack Overflow mentions the Range header, but I can't just magically use this as a client - the documentation will have to tell me what values are valid for this header. (Does the Range header even go in the OAuth signature? It seems not. Is this a security problem?)

• How do I even find the links in the first place? Look for any string in the returned data structure that matches ^http://? Presumably the response format needs to be documented, and responses are going to differ based on the sort of object I'm requesting, so in practice, you're going to have documentation that says 'responses for URLs under /books/ look like this', and your URL structure is exposed again.

• Am I allowed to make verbs up? Suppose I want to be able to flag a particular resource as offensive. Do I post to /books/4/offensive (how do I discover this URL), or POST offensive=1 to /books/4 (but I'm not changing the state of a book, so that doesn't seem right either)?

These aren't big problems. They have obvious solutions, even. But the solutions aren't covered by just saying 'It's REST' - you need to document them.

As a new developer, the main thing a purely REST API is going to differently is that, when I want to do pagination, the docs won't say 'add a page parameter', they'll start talking about Range headers. When I want to get JSON back instead of XML, I'll have to look at Accept headers. When performing operations on objects, they need to work out which verb is appropriate here.They will need to store complete URLs to your objects in their database rather than just IDs. (In practice, they'll just reverse-engineer your ID-to-URL mapping and store the IDs, then complain when you change something and their code breaks.)

Or maybe the developer will be using a high-level client that hides all of this, in which case there is no difference, except that your client libraries have to be a lot more complicated. But you've also hidden most of the benefits.

In practice, you will still end up documenting all of your different resource types, what URLs you can find them under, how to parse their representations, and how to find other objects based on those representations. You'll just have to document them using lots of highly-specific HTTP language, which means your documentation is going to be much harder to use for all the people using clients that hide all this stuff.

The best flickr clients (to my mind) are the ones with a call_flickr( method, params ) function, that takes one of the Flickr API methods, adds the parameters to it, does the authentication signing dance, and returns you the response, parsed into some in-memory data structure. To do this requires some knowledge of the Flickr API, sure, and I can't just point this client to some other web service's endpoint and get data out. But REST doesn't solve this problem either, and I believe it makes the simple things harder.

There have been a couple of things I've been linked to recently about how some APIs claim that they are RESTian, but aren't really - Gareth and Jens. To my mind, there's not a lot of clarity here. So.

Things that make your web service RESTian:

• Resources are represented by URLs.
• Resources can be cached according to their caching headers.
• You perform operations on those things using HTTP verbs (GET, DELETE, PUT, etc).
• You discover other resource URLs by examining other resources - for instance GETting the /books/ resource might return a document that contains the URLs of all the books.
• You can request a representation of a resource in different formats using the Accept header.
• Your API is stateless. (Presumably allowing for things like rate-limiting, of course)

Things that mean your API is NOT RESTian

• Your documentation describes how to construct URLs based on object IDs (/books/{id}) and is the only way of finding these URLs
• Your API has a single endpoint and you pass the method as another parameter.
• HTTP verb use is restricted to just POST, or POST and GET.

Things that have no bearing on the RESTiness of your API:

• Your APIs look meaningful (like /books/{id}).
• You return JSON. Or XML. Or anything in particular.
• You use the word REST in the documentation a lot.

Things that aren't magically true just because your API is RESTian:

• Writing clients is easy.
• You don't even need a client, you can just derive everything from a single endpoint.
• Your API maps properly onto your business objects and therefore makes sense.
• Your API will scale properly.
• Your API is easy to extend
• You won't get support requests from people who didn't read the documentation.

Hopefully this should help things a little.

If you disagree with anything above, mail me, I'm genuinely interested if I've misunderstood something here.

I also have my own opinions on REST vs non-REST. But I'm trying to be factual here.

Imagine that your task for the day is to localize a piece of software -- and luckily for you, the only output the program emits is two messages [..] how hard could that be?

[... some time later ...]

[..] where $directory_count % 10 is 2, 3, or 4 (except where $directory_count % 100 is 12, 13, or 14), the word for "directories" is forced to be genitive singular -- which means another ending [..] But with all other integer values, since "directory" is an inanimate noun, when preceded by a number and in the nominative or accusative cases (as it is here, just your luck!), it does stay plural, but it is forced into the genitive case -- yet another ending.

– A Localization Horror Story: It Could Happen To You - Locale::Maketext::TPJ13