On 7 April 2010 14:35, Stuart Charlton <[email protected]> wrote:
> > > 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. > Oh boy do they ever! > > > >> >> >> 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. > I agree that there is sporadic evolution (which is good) but the vast majority is just client/server. > > >> 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 ;) > Indeed. In the UK we have David Cameron. > > > >> >> 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... > Yup. Which I think stems from the original objections of the REST community to having a more formal interface description language. > > > > > >> >> >> 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) > Is that really a big difference? Sure the technology has changed but SQL was the "equivalent" back then. Sure HTTP/URI is more open but the net effect is still client/server just using a different (but better) technical protocol. Architecturally its the same even if in implementation its different. > > > 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? > This was the "vision" that MIME and "dynamic" REST based interfaces would enable the "automatic" consumption of services. Its me grumbling (yet again) that the technical myth of dynamic interfaces is rubbish while more structure published approaches (such as the Apple APIs) seem to actually work despite their technical "limitations". > > 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.. > Whoop de doo. Yup that is wonderful, but functionally what does that mean? It means punching a URI into another interface. Semantically the exchange is null. These are all "nice" features and benefits of using HTTP/URI but in terms of progressing towards integrated systems its the same as "email" or opening a screen on another display in X Windows. > > Sure, there are plenty of counter examples of isolated services if you look > for them. that was, after all, the historical norm... > My point is that the key change is actually mental not technical. REST, WS-* or whatever don't actually make the difference. People build federated solutions before HTTP/URI and are building client/server after it. The challenge is conceptual change not technical change. > > 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'm an X-Windows boy. Windows was a toy before NT! > > 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. > I worked on programmes where we exchanged information between systems across geographies and domains but in a very restricted domain. I'm not disagreeing but just saying that its the conceptual model that matters more than the technical one in actually delivering change and we haven't created a decent conceptual model to really replace client/server. > > 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... > I think the Semantic Web stuff is a bit rubbish to be honest. I don't think the maths behind it stack up and again I think that explicit ontologies are better than dynamic ones. Steve > > Stu > > > ------------------------------ > > *Yahoo! Canada Toolbar :* Search from anywhere on the web and bookmark > your favourite sites. Download it now! <http://ca.toolbar.yahoo.com/> > > >
