mjs

"bolted-on support for concurrency"--just what are your options when it comes to concurrency and C?

I thought the "changing underneath" in the title was referring to "hot" VM migration too (i.e. no downtime, but different physical hardware, like http://wiki.xen.org/wiki/Migration) but I think it's a bit picky to object to the way it's used in this blog post, even if it's slightly confusing... What other short phrase would you use?

I don't really get Laravel. The docs talk about dependency injection but at the same time they really really love static function calls. For example there's no event manager class, only a single, global event manager: e.g. "Event::fire('loaded')".

What if I want to use a different event manager? (To pass event calls across the network, for example.) There doesn't seem to be any way to do this, and pretty much all the core classes are like this.

http://laravel.com/docs/events

I think that's going to be difficult, at least initially. It looks like you at least get a MySQL client though, and it can run WordPress with only a few changes: http://www.hiphop-php.com/wp/?p=113

HipHop is incredibly promising, though it basically wasn't used outside Facebook in 2012. I hope it will get more adoption in 2013, which (as well as the performance benefits) should make PHP play a bit better with the Heroku-style services. (Since it makes a full-on web server unnecessary.)

I'm really hoping Knuth doesn't discover how bad his books look in their Kindle editions, he's already had to fix this problem once... http://en.wikipedia.org/wiki/TeX#History

I don't believe this is true. I've set up a Facebook account, and provided Facebook an email address only, and had reasonable "Friend Suggestions" appear presumably based on the presence of that email address in other people's address books.

Facebook says that they save the contents of your address book, and that it might be used to suggest friends in the future: https://www.facebook.com/help/241275309301947/.

> Right. The idea is that you use app specific ones at first, then, as you find they're useful and stable, you make them a generic one.

Ok, but do you think there will will ever be a generic definition of "user" or "product" or "photo" that can access the full experience of e.g. Amazon, Google, Facebook, Flickr and GitHub?

Regarding Atom, Google adopted a extended version of Atom in for some (but not all) of their products, but no-one else adopted it in almost a decade, and Google are now deprecating it. (I'm sort of blurring the difference between link relations and media types, but they seem entwined.)

URIs and shared media types are great for interoperability, but my guess (we'll see if it comes true) is that pretty much anything beyond that isn't going to get traction. Hypertext was around before the web, but I think a big reason it took off is because had very loose interoperability demands. (e.g. links can break.)

Well, companies seem to like to brand their dashboards, emphasise different aspects and so on. But still, I agree it would be really cool if you could use the same API browser everywhere, to avoid crappy dashboards, and that HAL would could enable that.

How can I point the HAL browser at foxycart's API? Or even see Foxycart's browser? I can only find standard hand-written documentation.

RSS is a great example, because about the most sophisticated link relation in RSS is a link. But there seems to be a big difference in kind between what's being suggested for hypermedia APIs and the example of RSS.

With RSS, the client doesn't need to know very much--only one method is supported (GET), it corresponds to a click, and you'll almost always get one media type back (text/html). The IANA define some other generic link relations, but there seems to be a very big gap between generic link relations ("self", "back", and so forth), and application-specific link relations that are necessary for non-trivial apps.

How is GutHub's API useful to hypermedia libraries? A "library" that could be shared between GitHub and a different endpoint would be maybe 10 lines of code? HAL has a bit more structure, but we're talking maybe 100 lines of code. (Versus URI templates, which must be hundreds of lines, and with much more complicated rules.)

Sorry, I don't get what you're responding to. Browsers don't understand hypermedia APIs (or even HAL)--they only grok HTML.

Oh! If that's the sort of thing we're talking about, then I'm all for it. The proponents of Hypermedia APIs have been saying a lot of vague things about how it will enable automated clients, and I assumed that the clients they had in mind would be able to do something useful with arbitrary APIs.

But it's clear from GitHub's API that it will do nothing of the sort: those link relations (and even concepts) are very much GitHub specific, and no machine will ever be able to figure out what to do with the them, what methods or media types the endpoints support, and so on.

(I'm not sure that it adds very much over a text document that that gives the relations and how to generate endpoints, but at least it's cheap to produce, and not actively harmful.)

A few thoughts:

* Mike Kelly (the author of the HAL spec) is not aiming for a universal API client http://news.ycombinator.com/item?id=4949357 (and also seems to be under the impression that no-one else is either).

* A universal client seems impossible because APIs will typically need to use service-specific link relations for all "interesting" relations (e.g. product, author). You might be able to share generic link relations (like those in IANA's table: http://www.iana.org/assignments/link-relations/link-relation...), but sharing only these doesn't seem to be worth the effort.

* Hypermedia-powered experimentation is kinda cool, but you're still going to need something to drive it (see e.g. Kelly's HAL browser http://haltalk.herokuapp.com/explorer/hal_browser.html#/), at which point you might as well write a full-fledged API dashboard.

I can imagine Twitter publishing a application/tweet+json media type or similar, and clients and servers either supporting this or not (and exchanging Accept headers and 415 Unsupported Media Types as they go), but I don't get what that has to do with HAL.

For example, the "comments" link relation in

http://developer.github.com/v3/pulls/

points to

https://api.github.com/octocat/Hello-World/issues/1/comments

but no-where in the document does it say what media types that endpoint will accept.

Well ... the spec does say "HAL is a bit like HTML for machines, in that it is generic and designed to drive many different types of application." To me (and perhaps DHH), that suggests that it's designed to be used to create clever clients. Perhaps you can clarify this point in a future edition of the draft?

http://stateless.co/hal_specification.html

Ah, maybe I misunderstand what you're trying to do. I thought Hal was trying to make it possible to write clients that can buy from Amazon or eBay without knowing anything about the specifics of either. But actually what it's attempting is a sort of machine-assisted documentation system? (Since you still need a human to read the docs to find out how to signup, place orders, and so on.) I can see how that might work, but it doesn't seem like an important problem to solve.

Do you mean like http://haltalk.herokuapp.com/rels/signup? But every site will have different requirements or mandatory fields on signup, so there's still no "discoverable" way to sign up to Amazon and eBay and Google without a human looking at http://amazon.com/rels/signup and http://ebay.com/rels/signup, etc., in which case you're back to still needing to read the documentation.

I guess it's a slight improvement to know exactly where the documentation for a particular link relation will live instead of having to search for it, but it doesn't seem to solve an especially difficult problem.

Are there any examples of what, for example, the Flickr or Twitter API would look like under hal+json?

I'm struggling to see how application/hal+json would help me write a client to upload a photo. I imagine that with or without hal I'm ultimately going to POST the data to some endpoint. The question is, how do I figure out what endpoint to use?

Without hal+json I need to read the API docs to discover that "/photos/" is the correct endpoint to post to. But with hal, it seems I still need to read the docs to discover that within the hypermedia file, the key "photos" holds the value for the URI template. So either way, I need to read the docs, and either way, my client breaks if the meaning of the string "photos" changes.

Doesn't that Schneier quote only apply to symmetric algorithms (e.g. AES)? I thought asymmetric algorithms (e.g. public/key systems like RSA, as in the original question) have completely different characteristics and rules.

"NIST key management guidelines further suggest that 15360-bit RSA keys are equivalent in strength to 256-bit symmetric keys."

http://en.wikipedia.org/wiki/Key_size#Asymmetric_algorithm_k...

Does this use "native" OS X components?

Well, they're the only ones that got into trouble. Maybe 1000 people did realise.

Much better than Apple Maps, but still:

* The Hayward Gallery is in the wrong place: http://here.net/united-kingdom/london/museum/hayward-gallery... * Searching for "Dover Castle" goes to the Castle in Dover rather than the pub <500m away. (There is a drop-down list which has the match I want, though.)

And the non-Retina resolution tiles are annoying. Do Nokia's high-resolution phones get the same tiles?

"Here is available through a Web browser and as an iPhone app." Anyone know how to get the iPhone app? Doesn't come up on the store.

EDIT: Ah, the answer comes later: "Skillman also showed off the iPhone version of Here, which will be available as a free app in the next several weeks."

FWIW, it's okay for me (London).

How does knowing the altitude help figure out which satellite to look for? (Are GPS receivers "directional", anyway??) GPS satellites orbit at ~20,000km; for the initial acquisition I'm surprised that receivers would care if they're 0km or 1.5km from sea level.

"The BlackBerry® 10 platform has recently achieved FIPS 140-2 certification"--not sure how meaningful this is if you can become certified months before the final hardware/software is available...

The JS assets 4 through 8 all commence loading at the same time.

Well, images.apple.com is Akamai'd (22ms for me) and it also supports keep-alive.

The mod_pagespeed service does some of these optimisations (plus others). It's almost certainly applying JS concatenation, and in the end there's not much difference in load time:

http://www.webpagetest.org/result/121024_K0_78b60a17cae988da...

EDIT: Actually, it is applying some concatenation, but it's not concatenating everything: http://www.webpagetest.org/result/121024_35_049258ec5056f5b4...

Concatenating JS doesn't necessarily make things faster, since (as the article mentions) modern browsers will download up to 8 assets in parallel. If JS is delivered separately, the browser doesn't have to wait for all of it to be downloaded before parsing and executing any of it--they can be parsed (and potentially executed) in parallel.