Gregg,

Why make an absurd point like this?  I seriously doubt Anne would suggest 
anything of the sort for a real time MMO.  Yet she is making a valid point for 
the majority of iApps that are focused on information sharing and authoring.

I'd note that World of Warcraft (I am a regular raider) makes heavy use of HTTP 
and URIs, through add ons and the armory, both of which are essential to the 
game experience.  WoW also does not use UDP, it uses TCP for its protocol.

Same goes for other systems with custom protocols, like BitTorrent.  HTTP and 
URI provide signaling.

cheers
Stu 

Sent from my iPad

On 2010-04-07, at 11:04 AM, Gregg Wonderly <[email protected]> wrote:

Anne, are you suggesting that Blizzard Entertainment Inc., if they port 
World-of-Warcraft to the iPad, should convert to using HTTP and URIs so that 
the 
lag response will be reduced and the users will have a much better experience 
than they have now on desktop/laptop devices?

Can you provide some details of how HTTP provides less lag than UDP does, and 
how TCP resend delays are no longer a problem in real-time multi-media systems 
because HTTP is used on top of TCP?

Gregg Wonderly

Anne Thomas Manes wrote:


Responding to this specific comment:

   "HTTP and URI (which isn't REST) "


Well, actually, HTTP and URI *is* REST. Or at least it's the essence of 
REST. All interfaces, all interesting bits of information, all 
interactions, and all application workflow in a RESTful application are 
driven by HTTP and URIs. As Stefan Tilkov says, REST is using HTTP as it 
was intended.

REST is:

   * Everything of interest has an identifier and the format of those
     identifiers is uniform (e.g., a URI)
   * Every identified resource supports a uniform API (e.g., HTTP methods)
   * The application uses hypermedia to coordinate application state
     and the process flow (HATEOAS)

REST is entirely about HTTP and URIs.

If you intend to support the iPad as a UI device for your service, you 
should design the service so that client applications can interact with 
it using HTTP and URIs.

Anne

On Wed, Apr 7, 2010 at 2:41 AM, Steve Jones <[email protected] 
<mailto:[email protected]>> wrote:



   On 6 April 2010 17:29, Stuart Charlton <[email protected]
   <mailto:[email protected]>> wrote:

        Long time no see.   comments inline


   Internet issues in Oz.



       Sent from my iPad

       On 2010-04-05, at 1:44 PM, Steve Jones <[email protected]
       <mailto:[email protected]>> wrote:


       The other piece that the iPad/iPhone has really demonstrated
       is how rarely services are actually re-used between multiple
       areas in the "web".  Sure there are a bunch of twitter clients
       but most people using Facebook seem to use the standard
       Facebook app and most other server/consumer applications are
       equally tied to a specific server side implementation that is
       used by only one client set.  Whether these elements use REST,
       SOAP or anything else is irrelevant as they are tied
       applications in a more client/server style mode than a "web"
       mode. 

       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.




       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).





       The iPhone/iPad do not demonstrate that REST rules, arguably
       they prove quite the opposite, they prove that a client/server
       model with proprietary APIs rules and that the "power" of the
       web is trumped hugely by a closed garden model.   

       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.



       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?





       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.

   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. 

   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.

   Steve



       Stu

       ------------------------------------------------------------------------
       Looking for the perfect gift?* Give the gift of Flickr!*
       <http://www.flickr.com/gift/>







------------------------------------

Yahoo! Groups Links






      __________________________________________________________________
Looking for the perfect gift? Give the gift of Flickr! 

http://www.flickr.com/gift/

Reply via email to