See inline Sent from my iPad
On 2010-04-06, at 11:41 PM, Steve Jones <[email protected]> wrote: The web currently is an extension of a client/server architecture... whether the client is a browser or a dedicated client is somewhat immaterial. Agreed, but this isn't the "vision" that is preached around the web architecture pieces. I guess it depends who writes them. Pundits have a knack for drama. For me the iPhone really demonstrates how little there genuinely is of the "web" application model and how in reality we are still at a technical client/server model with clients tied to servers. IMO part of this is driven by REST and its lack of proscribed documentation thus making interfaces obscure to anyone other than those who wrote it. I wont disagree that there is a lack of documentation.... but are you seriously claiming that crappy REST API's are responsible for why there are so many iPhone apps instead of just relying on browser-based apps? I think its part of it, but not on the iPhone apps v browser based but on the "tied" model of client/server rather than one service multiple clients (twitter aside). I think this is being improved in some domains: authentication via Facebook connect or OpenID, aggregation of content via RSS and Atom that drives sites like HuffPo, search suggestions across search engines in browsers via OpenSearch, etc. Lots of room to improve, of course. Last I checked, the best and most widely used application on the iPad was Safari. The multitouch web experience is easily the biggest draw on these devices. And that all of the apps, music, or vids you download from iTunes are available via hyperlinks that can be communicated and shared with others. And that nearly every application grabs its content from servers via HTTP and URI, and can allow you to copy those URIs and use them elsewhere. Not disagreeing but there is a jump from HTTP/URIs and REST as an architectural approach. I don't disagree that HTTP and URIs are absolutely key here. The jump is from the deployed architecture to the abstract and idealized style.... a common problem (look at politics, the difference between a liberal or conservative in theory vs practice ;) Yes, there are plenty of proprietary APIs layered on top of those standards. Time will hopefully help to standardize new media types where they are needed. But don't hold your breath on that one, its been 5+ years that people have been talking about that stuff and what progress has been made? Well, I'd say the REST know-how and community was pretty small through 2007. Since then, quite a bit has happened.... Oauth is an IETF working group. RDFa is being used in the wild along with Microformats. Atom extensions are being developed. The OASIS search services team are unifying a standard for search between OpenSearch and the Library of Congress protocols like SRU and CQL. And yet there still is plenty of reason to be frustrated. Crappy REST Apis abound, data still isn't any more interoperable with JSON, and HTML5 is deep in a mire... What the iPhone and iPad does is show the Web is not just about browsers. I think you are confusing the politicized process of HTML standards development with architecture. How can the world suddenly adapt all platforms to a new UI paradigm? It takes time to standardize deployed practice. The flood of iApps are an expected occurrence because a piece of the Web, HTML, has to catch up. Yet both HTTP and URI remain crucial (if incomplete) to the user experience on these devices. It is completely disingenuous to claim this is all proprietary client/server. It is, at worst, partially proprietary. Like most evolving information exchange protocols... What I'm saying is that while HTTP and URI (which isn't REST) are critical to the user experiences the actual service implementations are effectively proprietary (or partially proprietary if you like) in that a given server side implementation has a fixed client side. There isn't really an new UI paradigm, the iPhone, beyond things like multi-touch, is "just" a rich client platform and people are building client/server applications in the same way they always have by developing them together with the express purpose of them being used as a coherent lump that just happens to be split between a client and server. And I think a huge difference is that, no they're not building them the way they always have. issuing SQL via VB or Powerbuilder was predominant... the use of URI and HTTP are big, interoperable differences. Even for those trying to being that old model back for the Web (like Microsoft with OData) Its great that we've moved to a common protocol like HTTP and have a common approach like URIs but the "vision" of service assembly hasn't been delivered in reality by REST in anyway shape or form. I'm curious what vision this is.... that everything would be magical and automatically interoperate without work? or the current reality of Mashups and crappy REST APIs that are reasonably easy to build and consume? I think there is plenty of room for improvement, but the Web is a much more "assembled" set of services than it was not even 2 years ago. Think about how many sites have a "share this!" section on them that a couple years back was "send an email" but now is Facebook, Twitter, Myspace, Reddit, Digg, Livejournal, Wave, etc.... Or how many sites I can use my Facebook account to log in to. Or how TripIt consolidates all my travel points programs for me via mashup.. Sure, there are plenty of counter examples of isolated services if you look for them. that was, after all, the historical norm... So just to be clear HTTP/URIs are a good thing and are used pretty much everywhere 99% of iPhone/iPad apps are developed in a client/server mindset in the same way as client/server applications were developed 20 years ago. Yes, on Windows 3.0, people thought exactly this way.... :nod: ;-) I'll give you that Client/Server is still Client/Server even on the Web. But the infrastructure people build client/server apps today allows them to consume content from across server implementations, trust domains, and geographies -- something you could never do twenty years ago. What we do continue to lack are ways to make data content itself more interoperable, as the Semantic Web learning curve is pretty steep if you just want a little semantics. Though I see some positive signs there too, even if it will take a while... Stu __________________________________________________________________ Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now http://ca.toolbar.yahoo.com.
