On 12/12/06, Stuart Charlton <[EMAIL PROTECTED]> wrote: > > > > > > > > --- Steve Jones <[EMAIL PROTECTED]> wrote: > > > > You need to do the same standardization effort for both styles and > > I claim that defining a media type is a lot easier than defining an > > API. > > > > But that isn't a claim backed up by experience of distributed systems > > which has been successful via APIs but you are saying the new way > > _could_ be easier but don't have the proof point. You might be right, > > but I need data to back that opinion up. > > I suppose it's "proof by inspection" but one could also count the > number of internet nodes under different agency and observe how the > netwrok is used. Specifically, I'd look at the properties of the > popular application protocols that have a variety of implementations of > both client & server. > > The fact is that when one introduces a new media type, it works with > any of the Internet's Network-based APIs (i.e. transfer protocols). > Examples include HTTP, NNTP, FTP, SMTP, IMAP, etc. > > The key isn't necessarily using "MIME" specifically, it's the > importance of separating operation semantics from media type semantics.
Not disagreeing there, I just struggle to see this applied to business concepts rather than media types, which is what it is today. MIME is a good way of splitting up different types of content, I'm just not sure how good it is to apply in a blanket way to business concepts. > > I'd also note that HTTP is increasingly taking over from SMTP,POP3, and > IMAP as a way of sending & receiving email. There are many emergent > factors to why this is happening, but the properties required to enable > such emergence are arguably due to the architecture of HTTP. > > Approaches to Internet-scale computing with only custom operations & > protocols have mostly been successful if a single entity controls both > the implementation of both clients & servers (e.g. Napster, Blizzard's > World of Warcraft), unless the protocol has relatively simple semantics > to reverse engineer & cross-test (e.g. multi-network instant messaging > clients like Trillian). What about the world wide phone network? Its bigger than the internet, has multiple co-operative players and operates in a federated manner. You can argue that the specs are "simple" but that hides alot of complexity and indeed is the infrastructure on which the internet relies. The various banking networks have standardised protocols, but certainly do not have the same entity controlling the implementation at either end. And they handle massive data rates and scalability challenges. The current internet can't match their performance requirements Radar networks for multi-radar processing handle masses amounts of data and process the information in real time,. there are again standardisations of messages but there is not a standardisation of implementation at both ends. The internet can't match these performance requirements either. So I'd say that there are quite a lot of massively scalable infrastructures that have massive data throughput that have neither centralised control of everything and which don't use HTTP as their architecture. > > > > Really, I am totally not getting your point. Can you explain? > > > > You talk of standardized MIME types, a theoretical thing, being the > > Seems to be working quite concretely for Newsgroups, Email, and Web > pages today. I wasn't talking about video/image/etc types I was talking about business MIME types, which is what was being proposed, which are theoretical. > > > "solution", I doubt that we will get to a complete ontology of MIME > > types that is standardised across the globe and therefore REST > > MIME types are just identifiers, not ontologies. > To contrast, I don't > think anyone's aiming to create a global ontology out of XML > namespaces. They're both useful tools for disambiguation via > registries. I agree, but Jan was aruging that "all" that was required for two parties to communicate was a MIME type, clearly this isn't enough unless you have a MIME type for every type of information (e.g. not just app/xml, but app/invoice and app/overdueinvoice etc). My argument was you need Schema + MIME type to have a meaningful association between two parties. > > > WS-* is further along in the standardisation of industry verticals > > and > > this is liable to accelerate in the next 12 months. I'm just not > > seeing the business case for them re-doing the effort for REST. > > One arguably can create RESTful stanards on top of WS-*, though it's > unclear whether they'll flourish since they often lack cheap & robust > enabling infrastructure to complement the specifications. What is expensive about WS-*? > > OAGIS, for example, has done this very thing by separating nouns & > verbs in its specifications. These specifications are on the right > track to being RESTful, though they lack support of a standard set of > processing infrastructure to provide working, freely available, code on > how OAGIS proxies, gateways, etc. would work. HTTP & HTML had the > benefit of a freely available Mosaic and Apache in its early days. OAGi have a massive number of WSDLs already published, its true (as I've said) that you could ship lots of industry vertical schemas over REST... but I'd REALLY want a tool to do that as lots of those things are butt ugly (way beyond what Tim Bray thinks of as butt ugly, I'm talking 20 pints and eating both your arms off ugly). > > I don't think the REST camp wants anyone to redo their industry > vertical specs, as I don't think that's their area of interest. If > industries are successful with such things, that's great. But, > frankly, many believe (and I include businesspeople in this category) > that such efforts are a waste of time, since they'll inevitably be > subverted by competition. Most business people I see want to see standardisation in inter-party communication, this is because it rarely gives competative advantage and is a massive drain on costs, this is why OTA for instance has such large support in the travel industry. You probably deal with different business people to me, mine don't give a stuff about having a "better" XML interface to suppliers than their competitors, they just want a better business contract that their competition and for the technical interface to be as cheap as possible as it gives them no value. > > As an aside, if anything is true in this industry, there *always* is a > rebuild & respec of the infrastructure every 10-15 years. The old > stuff doesn't go away, but open source developers come up with new > ideas, academics create new theories, and vendors keep needing to sell > the next shiny thing. It will take a monumental change in the long > term investment valuation of software and IT assets for this trend to > change. One can hope.... IT has a severe case of ADD combined with Alzheimers. Not only do we keep going "ooooh string" but we also forget all the lessons we learnt last week. > > Cheers > Stu > > __________________________________________________________ > Any questions? Get answers on any topic at www.Answers.yahoo.com. Try it > now. >
