Over the holidays I thought I'd play with the Amazon and eBay web services APIs. What a contrast! I got Amazon working in a couple of hours, and eBay... well, it's two days later and I'm starting to feel stupid.
For Amazon, to get information on a product you just register to get an ID for your application, using your existing Amazon account if you want, and then you plug that ID into a link like this and the HTTP GET returns a bunch of XML. So you have your Amazon username/password, and one application ID string. There's also a "shared secret" used for any calls that require authentication, but most calls don't require it. Both application ID and shared secret are viewable online as part of your account.
Amazon has SOAP too, for masochists, but I think I remember reading that only 1% of their API users bother with it.
That's the straightforward way to do a web services API. Now let's see what eBay has. First, there are three different username/password logins and it's never clear which to type in. Since they're all on the same site, your browser will try to autofill the login fields, usually with the wrong one.
Here's what makes it even more awesome: the three logins at times I don't understand seem to interfere with each other by using the same cookies. So e.g. you can try to log in to ebay.com and it will redirect you to sandbox.ebay.com, things like that. Basically you need to use Firefox for one site and IE for the other or something. Which is fun since I can't keep straight which login is which in the first place.
After you create your account (one of the three), eBay sends one time via email three different ID strings; "developer ID," "application ID," and "certification ID." If you lose this email you are hosed, they're only sent one time.
Now you go to the "sandbox" fake-eBay web site and create a fake user. Only you don't want to do it on the sandbox itself because you have to make up all the bogus info (credit card, address, etc.); there's a tool to make fake users without entering all that, but it's not on the sandbox site, you have to find it separately.
Fake user in hand, you go back to the developer site and manually cut-and-paste into a form your three ID strings, and then log in as the fake user, and it gives you another ID string specific to the user. Only in my case it doesn't; it says one of my three ID strings is invalid. Stuck at this point (help?).
If I could get past that, then I could make an API call in the sandbox environment. But I still wouldn't be done. Next I'd have to go through a certification process and get three more ID strings to use with the production environment, generate another ID string using a production user account, and I think finally be able to make a simple API call to get real data from the site.
Let's review, to make one call you end up with:
This is to get public information that anyone could anonymously screen-scrape.
I haven't even started to complain about the API itself. Rather than a simple GET, you have to do a POST with special headers. You are already POST-ing an XML document, so the information could just be in the XML document; but nooooo. Then the headers include:
X-EBAY-API-SESSION-CERTIFICATE: devId;appId;certId
X-EBAY-API-DEV-NAME: devId
X-EBAY-API-APP-NAME: appId
X-EBAY-API-CERT-NAME: certId
X-EBAY-API-CALL-NAME: callName
So yes, you have to put in each of the three IDs twice (someone send eBay the docs on split() and join()); and you have to put the callName in there, even though it's also in the XML document. I imagine this is due to some internal system that wants to route via HTTP header, or some other implementation detail, but geez.
eBay does have prebuilt SDK code in various languages to do this for you, but to me one of the whole ideas of web services is that you don't need a special library SDK. I would much rather they'd spent time making it easy to use the service than coding SDKs in a bunch of languages.
Other frustrations I encountered:
What makes all this really painful is that in most cases it would have been better if eBay had just spent less time on it and kept developer site, API, and docs simpler. Instead of rolling out a Content Management System for their developer site, they could have just made their Getting Started page possible to find... seriously, I know I saw it but now it doesn't turn up in a search for "getting started" nor does it appear to be linked from anywhere obvious...
On the plus side, the eBay dev support staff seems pretty responsive in the forums (where there are lots of questions and confused people related to all of the above...)
Regarding GTK+ themes, I think the metacity approach to themes worked out pretty well. You could definitely improve on the details (inventing my own little expression language was kinda weird, and there are lots of feature requests for the format). But metacity themes are "just data" rather than code while remaining reasonably flexible.
Arguably you want to go even more in the direction of "just data" and keep themes to a pixmap-engine type of thing preferably with a GUI theme editor. Lots of theme designers don't want to mess with editing an XML file anyway.
Miguel, that's cool, I know SOAP (with a library) doesn't involve a ton of application code. My point is more that (to me) it's just not worth learning about for this sort of thing. If you want to get a couple of pieces of data on an Amazon product you just do "get url contents" and "stuff into XML parser" and "grab the Item node" and that's about it. All programmers already know how to download a URL and pull out an XML node, and being able to try out requests in the browser by editing the address in the location bar is pretty useful. "REST" is just very conceptually simple and requires no ramp-up time, even if it involves a couple more lines of code. But if you already know SOAP and have the library sitting there, by all means it makes sense to use it.
According to this Tim O'Reilly article the real percentage was 85% of Amazon usage is REST, 15% SOAP - just to set the record straight vs. the 1% I had misremembered.
For this particular task the transport protocol hardly matters; as you say the time is all in registering for the account and so forth. On that front Amazon via any protocol is way, way better than eBay via any protocol, I assure you!
i.e. the actual API and service design are much more important than how one gets the bits from point A to point B.
I think this is a debate I didn't intend to start - I concur that yes, there are lots of formats you can send over a socket and you can wedge most use cases into most of the formats if you try hard enough. A meaningful discussion of protocols though would recognize that "could possibly be made to work" isn't how one chooses a technology; you need to know the context of the usage - desired properties and tradeoffs, who is doing the coding and their knowledge, what's available on the platform, needs of customers or co-developers, whatever it is. Then pick something appropriate. It's not about One True Way.
As you illustrate, REST is a stupid choice for a desktop bus. I don't see how that's relevant to Amazon's APIs or to D-BUS.
My offhand remark about SOAP (in a very long post about something else) was intended to convey that personally I wouldn't mess with SOAP in the context of looking up some simple details of an Amazon item. It must not be that controversial a comment if 85% of Amazon API users made the same decision. But if Amazon only had SOAP (or CORBA, or some made-up protocol) I'd use it and not get especially hot and bothered. If I were using C# and already knew the SOAP APIs I'd probably use them then too, but I'm not going to install and learn a major new technology and API just to do something really simple.
For the record I'm not trying to say "SOAP sucks" or something. I don't know much about it or care either way until I have reason to use it.
As for D-BUS, it's a protocol/library that has certain properties that I felt were useful for two use-cases in the specific (social and technical) context of GNOME/KDE/Linux. The case that funded/motivated the D-BUS project was the systemwide bus, and D-BUS remains to my knowledge the only project that even attempts to implement such a thing for Linux. It seems to work fine for that. D-BUS tries to support a desktop session bus also, but secondarily, and it hasn't been much hacked on in that context. That's why GNOME still uses Bonobo and KDE still uses DCOP. Beyond those two use-cases, D-BUS has no aspirations to be an ISO-certified scalable enterprise middleware or Internet web services protocol, nor would I ever suggest it (or use it myself) for those purposes.
I'm happy to debate which protocol is appropriate for a particular context, assuming I have any knowledge of and interest in that context, but comparing protocols in the abstract makes no sense to me. There must be at least hundreds of thousands of protocols spoken over sockets out there in active use and it doesn't seem to be killing anyone. It certainly isn't keeping me up at night.
Ben, interesting that Europe has different sales numbers. For purposes of thinking about product design though, to me the $50 flash players are a distinct product category from the iPod or the Toshiba. People buy the small solid-state players for different reasons (and at $50, the reason need not be as compelling as the reason to buy a $400 gadget). iPod Shuffle tries to put the flash player into the iPod design vision, and Apple markets it specifically for jogging and other cases where you could not use the regular iPod. But the Shuffle's positioning and design is not typical of flash players and I don't know if it's been successful.
Not sure comparing absolute number of $50 solid-state players sold vs. $400 all-your-music players sold means much; it's similar to comparing CD-R sales to iPod sales, or Corolla sales to Mercedes sales. The success of the iPod was in giving people enough value over a CD player or radio that they wanted to buy a new product category with a base price in the hundreds of dollars.
"But they both play music" is a generalization that clouds thinking in my opinion. "Play music" is not specific enough as a design vision to understand a product and its tradeoffs; it doesn't explain how the product will be different from alternative products or product categories. It's like the empty mission statement "do good things well."
Dom - there are certainly other music players that work, but I would argue that the iPod was the first one to figure out the formula that defined its product category, and it continues to stand out.
Your point about marketing goes right to why I was mocking Toshiba's new campaign. I think you are wrong to say that Apple's marketing is better because of the marketing budget; though that doubtless helps, to me a fundamental reason their marketing is better is their understanding of the product design. They don't waste their breath on irrelevancies like "music is better in color," nor do they bombard you with feature lists. They know what the product was designed to do and how it was designed to make you feel. And they market it by telling you exactly that. The visual and emotional design are part of it; far from merely cosmetic, they make people like the product more.
You and I might bother to research the iAudio (I did when I was shopping for players), but their marketing blows goats. I just went to their X5 product page (can't link to it because it's all flash), and their front-and-center pitch is a huuuuuge feature list, where many of the features are irrelevant noise. Most people are going to tune that out in a hurry. And let's not neglect the marketing handicap of the unknown brand name.
Apple seems to be sinking further into feature wars recently, as they try to distinguish their new iPods from their old ones - their product web site used to be better. But in particular their TV ads still stick to the emotional experience of the product.
Unlike the iAudio people, Toshiba and Sony and friends have large marketing budgets. But if they waste their money saying the wrong thing, the budget won't help them vs. Apple. You can see Toshiba's lack of understanding of the product in both their implementation/engineering and in their marketing message.
Calum brings up the music store; another important thing about Apple's approach is that they understood the user experience to be more than the hardware device. It includes the store, the iTunes software, and yes, the marketing. I'm hardly an expert in music player history but I don't think anyone else had put all the pieces together before Apple did.
BTW, one word that waves the big red flag of Clueless is "content" (with "media" as some kind of synonym). Whenever you see someone saying "content" you know they're being too imprecise to think clearly about product design. When was the last time you heard a non-technology person wandering around saying "I wish I had a better way to access my digital content!" Apple is notable for using specific words like "music" or "photos" almost always (in both marketing and user interface).
It blows my mind that you can go to Apple's web site and just read what makes the iPod a better design than most music players, but their competition can't seem to figure it out. So Apple continues to crush them. It's just not that complicated: the iPod lets you listen to all your music. That's it. Apple gives you the design secret right on their web page, saying things like "you can put all your music in your pocket." That's why it's better than a CD player.
If you have that design principle, you can know that the following things aren't all that important:
Original iPod had none of that compared to the competition. Those things can be nice, but only if they don't break the core: a convenient way to listen to all your music. The big amazing secret to Apple's design is simply knowing what the heck the device is for and consistently applying that knowledge.
Note the iPod Shuffle. Apple's flash player still preserves the "listen to all your music" aspect, with the "randomly shuffle new songs onto it every day" trick.
Similarly, I remember reading that they wanted to be able to jump to any song in some small number of clicks. Again, all your music, at your fingertips. There's a design vision here. They know why it's better than a CD player and focus on ensuring the details of the product support the design objective.
This isn't the same as saying the iPod is "user friendly." "User friendly" is just another lame checkbox in a lame feature list. Design goals resolve tradeoffs; "user friendly" does not. "User friendly" is like an empty company mission statement that fails to distinguish a company from its competitors: "our mission is to sell stuff, and be a good company to work for." Design goals will always be notable for how they are not shared by other possible and actual products; they eliminate as many directions as they add.
Other music players keep taking a feature-list-based approach to their product. They are all "our player has more megapixels!" or "we support 613 different codecs!" or "now with 53 buttons instead of 3!" or whatever. They mishmash the tradeoffs in an incoherent way, never focusing on clear design goals and thus unable to decide what's important. If you don't understand the design, you don't know whether small size or 40GB hard drive is the more important feature.
What brought on this rant? Today I saw a music player package with a screenshot of a terrible-looking UI and the prominent tagline "Because Music is Just Better in Color." It seems this is Toshiba's big idea for their line of music players.
Last I checked, I don't give a crap how many color megapixels my music player has. I can't believe they are making a mostly-irrelevant feature the center of their ad campaign. They may as well write Clueless About Product Design in magic marker on their forehead.
Sure, iPod Photo is cute, but it's not why the iPod is a big seller.
Thinking about Morten's comment, one of the main goals of GtkTextView was to keep everything better than O(n), because I'd seen so many posts to gtk-list where people inadvertently wrote quadratic code with GtkCList and the old GtkText. (Those widgets also had the evil freeze/thaw convention, where you could "freeze", do stuff, and "thaw" and it was supposed to magically make the "do stuff" fast. Mostly it made the widgets crash by creating strange code paths.)
The idea with GtkTextView is that for the most part you can just use it and it's scalable and things are fast. Lots of internal complexity to enable that. We had a good starting point with the TkText btree and we improved on it a fair bit.
However, there's one exception to the scalability, and that's long paragraphs. GtkTextView has code that's O(n) in number of characters in a paragraph or number of "segments" (analagous to XML text nodes) in a paragraph. (Note, paragraph is the same as a newline-terminated line.) There are various bugs about it, but it would be extremely hard to fix. It is mitigated somewhat by the crazy overengineered iterators. Pango also works on the level of paragraphs (PangoLayout) and really can't do units of work below the paragraph level, so you can't do something like incrementally lay out only part of a paragraph.
I have no clue how you'd make the whole stack support really long paragraphs, without using reams of memory of creating some scary(-er) code. But it's probably possible (I imagine word processors do it). Not sure it's genuinely a problem in real life, though.
The official listing is up, you should submit your resume online there for HR tracking if interested. Feel free to also email me with JOB in the subject, as mentioned before.
Quotes I enjoyed today, first from Steve Jobs here:
This stuff doesn't change the world. It really doesn't ... Technologies can make it easier, can let us touch people we might not otherwise. But it's a disservice to constantly put things in a radical new light that it's going to change everything. Things don't have to change the world to be important.
And from Shigeru Miyamoto illustrating the epic battle of Design vs. Megapixel:
You know, in regard to the power of the Nintendo Revolution versus, say, the Xbox 360, we're looking at making a small, quiet, affordable console. If you look at trying to incorporate all that, of course we might not have the horsepower that some other companies have, but if you look at the numbers that they're throwing out, are those numbers going to be used in-game? I mean, those are just numbers that somebody just crunched up on a calculator. We could throw out a bunch of numbers, too, but what we're going to do is wait until our chips are done and we're going to find out how everything in the game is running, what its peak performance is, and those are the numbers that we're going to release because those are the numbers that really count.
While I liked the Jobs quote in all seriousness, I am also compelled to point out this example of something important that will not change the world. We definitely need a GNOME feature that does this. Write one. Do it.