
Learning from our Mistakes: The Failure of OpenID, AtomPub and XML on the Web - BarkMore
http://www.25hoursaday.com/weblog/2011/01/30/LearningFromOurMistakesTheFailureOfOpenIDAtomPubAndXMLOnTheWeb.aspx
======
deno
I'm very interested whether fellow HNers consider AtomPub a failure? The
article points to not so great adaption, but in fact AtomPub has been embraced
by some major players—i.e. Google which uses their GData for every one of
their dozens APIs[1] and Microsoft which is now pushing OData to be used for
.NET based services[2].

It seems AtomPub isn't that terrible idea—you get uniform envelope format, so
you can use feeds to represent your data in any way you like, because each
entry has its own unique id. AtomPub let you use many conventions that web
developers are already familiar with—e.g. <link rel="alt"/>, various
extensions like OpenSearch etc.

If you are API author would you consider using AtomPub (or GData/OData)? Do
you consider it too difficult/inconvenient to implement?

If you are using any AtomPub (GData/OData) based API what are your
experiences? Do you consider it too difficult/inconvenient to consume?

[1] And provides JSON support: directly by translating XML tree as JSON
structure (and I was sure they had something called cJSON, but now I can't
find reference anywhere so I might have been dreaming that.)

[2] I don't know .NET world that good, so anyone please correct me if I'm
wrong.

~~~
steverb
I think AtomPub suffers from the same problems that SOAP does. It's too
complex for what it does, or at least it feels that way. The fact that major
player have adopted it doesn't change things, as many major players adopted
SOAP.

I don't think it (or SOAP) will just vanish though, it just isn't having the
impact its creators had hoped it would.

~~~
deno
I'm surprised that perception would exist. It's really a shame if that's (in
addition to JSON hype[1]) what has killed Atom.

The main difference between SOAP and Atom is that I can explain the latter to
anyone in 5 minutes. Actually that's what some Google engineers have exactly
done and you can find the results on YouTube.

And there's plenty of XML APIs and JSON APIs and each one of that APIs
reinvents the concepts of feeds and entries, because those concepts are very
natural.

Anyway, I understand that AtomPub just isn't very popular[2], but I was
interested in any technical difficulties that may arise for both services
providers and consumers. That is, if I were to implement API for NextBigThing
and were to implement AtomPub-based API, could that be a problem for anyone?

Well, I guess it's a shame I haven't had a chance to get this discussion going
while this story was still on the front page…

[1] Which went from "XML is too complex, fuck it; Let's just dump our internal
data structures and be done with it" to "Oh, now I understand what that schema
thing is supposed to do; it's kinda neat. Let's just re-implement it in JSON."

[2] Actually it seems extremely anti-popular if you just go to ProgrammableWeb
and filter several thousand APIs by protocol; there's only one page of
results!

------
d_r
The other day I wanted to log in to my StackOverflow account. I was presented
with this screen: <http://i.imgur.com/SwuVJ.png>

Shoot, did I previously log in to SO with my Google account? With my Facebook
account? How can I remember? Or maybe, I created a "myOpenID" account? After
trying various combinations, I became frustrated by the error "No OpenID
endpoint found."

Finally, I ended up spending twenty minutes digging through my old e-mail to
figure out that I did, in fact, create a dedicated OpenID account at
myopenid.com.

It turned out, for some ungodly reason, that I have to enter my OpenID as
"[http://<my](http://<my) username>.myopenid.com/" -- I would not have ever
guessed this.

As a developer, I can appreciate the motivation behind OpenID. But the
execution is simply frustrating.

~~~
drdaeman
I don't get why people create ton of OpenID identities, then use them in a way
they can't remember which one they use where. I have one "main" OpenID URI per
identity (with several "backup" ones, which I use on sites who allow me to
associate multiple OpenID URIs with the account) and have never experienced
such kind of problem.

OpenID is fine in this regard. The root of the problem in lack of site with a
_short and concise_ explanation _what_ OpenID is, and best-practice tips on
_how_ it should be used. With all contents in public domain or under very non-
restrictive free license.

Also, I'd note that the problem you mention is the same for
passwords/passphrases. I.e. you have to remember whenever you used one
password generator or another (I, unfortunately, have two, because due to way-
too-smart sites which decided they won't accept some ASCII non-alphanumeric
characters, passwords made by first one, while being secure, weren't allowed
to use), or the site was a special case where you typed man-made password.
"Did I use my X password here? Or my Y password?" - it's exactly the same.

~~~
wahnfrieden
If you forget your password, you can have the site reset it for you, as long
as you have your email, generally. You can't have the site tell you which
OpenID endpoint you used though.

That you think OpenID fails because there is no concise explanations of best
practices and tips is damning enough. Most users aren't going to read that
stuff.

~~~
drdaeman
> as long as you have your email

Email is exactly the same as OpenID in this regard. Your forgot-which-OpenID-
was-used could be compared to forgetting which email address was used. And
this is, actually, popular. It's just a hype that everyone's talking about
OpenID - totally forgetting that traditional systems have the same problems.

If you're doing it right - by having _one_ primary OpenID URI (per identity) -
you won't really forget what your OpenID is.

> Most users aren't going to read that stuff.

Nor passwords, nor OpenID were ever intended to work around this kind of
problems. And I doubt there's any solution at all. Users will always forget
all sort of things, use and reuse totally insecure passwords, keep their
backdoor open wide with silly "password recovery" questions anyone could
guess, leak all kinds of sensitive information and whatever else they could do
wrong.

Sadly, "OpenID sucks" became a meme. And this is the main reason why OpenID
suck now.

------
olalonde
What's up with all the OpenID hating?

I personally find OpenID totally awesome (not that it couldn't be better) when
I want to try a new service and don't want to go through a registration form
or hand out my password to an untrusted website or when I'm too lazy to type
my username/password.

~~~
tzs
I think OpenID ran into serious trouble when a bunch of big sites announced
support for it, but really only supported it as providers, not consumers.

At one point, I had something like 3 or 4 different sites I was registered on
that would serve as OpenID providers for me, but not a single place that I
wanted to login to accepted OpenID. At that point, I pretty much forgot about
OpenID. I bet a lot of would-be early adopters did the same.

By the time I actually started occasionally encountering sites that accepted
OpenID and that I wanted to use, I had 1Password and didn't care about OpenID
anymore.

------
random42
Is XML considered a failure? (Not being snarky, just that I find it in use
_everywhere_.)

~~~
j_baker
I don't think it's fair to call XML a failure any more than you can call Perl
a failure. XML does the job, and it's still used in a lot of places. It's just
that it's being supplanted by a newer technology that is superior for the
majority of use-cases.

~~~
joe_the_user
XML is being abandoned as the medium for a variety of APIs at the moment
(Google and Facebook especially). It looks like failure when my XSLT code
deprecated before I can even release it.

------
erikabele
IMHO the only issue with OpenID in regard to its adoption is how it is
presented to the user. He/she shouldn't have to deal with URLs or even the
term 'OpenID'. Unfortunately the current UIs & the whole UX are solely
engineer-driven...

~~~
Joakal
Showing OpenID term makes sense as it's branded to be an alternative access
choice for users who wish to use OpenID. You are right in that it's poor UI/UX
but unfortunately it's the implementation of 3rd parties.

Facebook is implementing a similar proprietary alternative login:
FacebookConnect.

------
Ixiaus
XML is not a failure and it's also not a failure on the web (XHTML? RDF? FOAF?
&c... _huge successes_ ). OpenID also isn't a failure - it could stand to be
supplanted by something better but it had to start _somewhere_.

~~~
halo
>XHTML? RDF? FOAF? &c... huge successes

You're kidding, right?

~~~
Ixiaus
No I'm not. What in my tone makes you think I'm kidding? Could you please
provide a counter argument instead of a flame bait comment?

~~~
beaumartinez
XHTML hasn't revolutionised web page markup (it brought with it draconian
changes {read: made web page markup more XML-like} and is now being replaced
by HTML5, which makes some {all?} of its changes irrelevant).

RDF isn't as widespread as it could be (it could be used in Facebook and
Wikipedia but isn't, for example).

(And I haven't even heard of FOAF.)

I wouldn't call these _huge_ successes.

~~~
Ixiaus
XHTML has revolutionized page markup. Not because everyone is using it but
because it blazed the path for better standards that the other document types
follow. Also, many of the changes in XHTML _were_ brought over to HTML5 -
which does have an XML definition.

~~~
yuhong
"Also, many of the changes in XHTML were brought over to HTML5 - which does
have an XML definition."

Yea, the so-called XHTML5 that will be finally supported in IE9, BTW.

------
AndrewO
I was with him until the last paragraph. The NoSQL trend is about bringing
more options to the table when solving your specific problem, not trying to
take a solution to a specific problem and make it general (as he claims
OpenID, AtomPub, and XML do). He's right in saying developers should evaluate
it and lord knows there's a lot of hype, but it's hardly related.

Now, if SQL were the new thing and had been developed by a group trying to
make a standard API for CRUD operations based on some new generalized
"Relational Algebra" concept that they extracted out of a couple of company
payroll applications, I'd say he was onto something.

------
Lewisham
I think one of the mistakes this article makes is believing that people know
what they want upfront. We all know that people are very poor judges of what
could and couldn't be useful to them before you actually give it to them.

OpenID should probably have seen it was overly complex, but I'm not sure how
anyone could have guessed that XML was going to be shunned in favor of JSON.
It does have some pretty cool advantages, such as DTDs ensuring correctness.
It's just that it got a lot of typing real fast (and probably was never
supposed to be written by humans anyway) and the space sizes blew up too.

~~~
Swizec
From personal experience I think the reason JSON won over XML is simply
because it maps to OOP/dictionaries _much_ better.

In most scripting languages reading JSON looks like this: x =
json.parse(string) and saving it looks like this string = json.dump(x) ... The
rest of the app looks the same as if JSON was never in the picture at all.

Now with XML, hah, in most scripting languages you have to instantiate a
parser, then use strange xpath traversal methods that are different depending
on which parser you use and os on. And don't even get me started on generating
xml programmatically ...

Sure, I understand why handling XML has to be so much more complex, it's got
attributes and a few other nifty things I will _never_ have a use for.

JSON vs XML --> simplicity always wins over more features.

~~~
BarkMore
JSON won because there's a straightforward mapping between a JSON document and
the language's native arrays, maps and values.

The remainder of the problems you list are not problems. There are one line
parse and dump functions for XML. You don't need to use xpath to traverse a
document. The result of parsing a document is the same across each OS (at
least in Python, Ruby, Java, Go and other languages that I have used). An
application shouldn't need to use more than one parse, so it does not matter
that different parsers represent the DOM differently.

------
mryall
Interesting summary and juxtaposition of various opinions on these
technologies.

The fact that JSON has won over XML on the web says a lot about the
technologies people are using to build websites these days. JavaScript client-
side data processing seems to be a lot more popular than server-side
processing with an XML-loving language like Java or C#.

~~~
__david__
You're right, but I think it speaks less to client side and more to current
trends in server side technologies. The #1 feature of JSON is that it maps
directly into the dictionary and array built-in types of all the popular
"scripting" languages (Perl, Python, Ruby, Javascript, PHP). This makes it
absolutely trivial to work with in both the browser and the server unlike XML
which demands either DOM traversal to extract data (yuck!), or XPath (cleaner,
but yet another thing to learn).

I think this points to Ruby/Python/Perl/Javascript becoming more and more
popular on the server side, even for "serious" apps.

~~~
j_baker
I agree. JSON is inherently dynamically typed. Trying to make it work in a
static language is a pain just like using XML in a static language.

------
techtalsky
You know, no one's saying this, but I'd just like to point to Douglas
Crockford's accomplishment with JSON. Crocker thought of a really bare bones
way to represent data that works in a huge number of cases people tried to use
XML. XML has not lost, in any way, shape or form, and people will be using it
to represent and structure data for a long time to come.

We can just be glad we have such a simple, common data structure before people
start writing insanely complex data interchange formats on top of it. You
could just as easily write SOAP in JSON.

------
goopot
I'm slightly dubious as I'm reading on my mobile browser, but I'm getting a
404 for this page. Can anyone else see it?

~~~
muuh-gnu
I see it, but I clicked away as soon as I saw that the guy writes under the
name "Carnage 4 Life" and is proudly quoting some ridiculous gangsta rappers
in his headline. Whatever kind of content he then may have below that, then
simply does not matter any more.

~~~
tzs
A guy posting as "muuh-gnu" responding to a post from "goopot" has no business
complaining about the name someone else writes under.

And what was wrong with the quote? Do you disagree with it and think respect
can be bought?

