Sorry, Steve, but so many of your statements here about REST (and about innovation) are IMO so wrong on so many levels that it would take me at least a week to properly answer them, but I have neither the time nor the patience to do that.
(While this response may seem unhelpful, I felt I had to say something so that people wouldn't assume that my lack of response implied agreement.) --steve On Dec 18, 2006, at 8:15 AM, Steve Jones wrote: > On 18/12/06, Steve Vinoski <[EMAIL PROTECTED]> wrote: >> >> >> >> >> >> >> On Dec 15, 2006, at 11:07 AM, Steve Jones wrote: >> >>> On 15/12/06, Mark Baker <[EMAIL PROTECTED]> wrote: >>>> On 12/15/06, Steve Jones <[EMAIL PROTECTED]> wrote: >>>>> or c) start an underground movement >>>>> of people using it in the belief that "everyone will come to >>>>> realise". >>>>> >>>>> The later is often the worst of the two as it tends to explode >>>>> in a >>>>> mess, where as the first can often be ignored by good software >>>>> architects and designers. >>>> >>>> Hmm, so how are people supposed to distinguish between that >>>> situation, >>>> and an honest-to-goodness improvement on the status quo? Or do >>>> you >>>> believe that if it was an improvement, that everybody would >>>> immediately recognize it as such and adopt it, despite the fact >>>> that >>>> it is likely to be disruptive to vendors with entrenched >>>> positions in >>>> the market? >>> >>> No I think if it was a genuine improvement they would be able to >>> _demonstrate_ the improvement to _communicate_ why the change was >>> required. >> >> Maybe, maybe not. Mark mentioned Clayton Christensen's "The >> Innovator's Dilemma" elsewhere in this thread. I strongly urge >> you to >> read it, otherwise you won't ever understand Mark's point or the >> point I'm about to make. > > Which I have.... one of the big problems with IT though is that > everyone thinks that _they_ are the innovator (Agile "inventing" > iterations for instance, and that in fact they have discovered the > silver bullet. > > The innovators dilemma is only that if you are actually disrupting in > a way that will change markets. Having another way of calling remote > capabilities is not innovative. > > >> >> Whether an improvement can be "demonstrated" or "communicated" >> depends not only on the demonstrators/communicators, but also on >> those receiving the demonstration and communications. If the latter >> fall into the risk-averse category when it comes to technology >> adoption while the former fall into the risk-taking category, they >> can talk all they want, and they'll *never* understand each other. >> That, in fact, explains a lot of the miscommunication and >> misunderstandings that have plagued this thread. > > I've had a bit of a track record of either doing or supporting the > uses of innovative technology or old technologies in innovative ways, > quite a lot actually. I've also had a record for stopping lots of > dumb decisions based on _assumed_ innovation. > > I'm pretty sure apart from some basic mistakes (like me thinking that > Amazon was doing REST) I'm there now with REST. But I _still_ don't > see any value or actual innovation. Its fine to say "well that is > your fault because you just don't _understand_ us", but that is a > brave statement at best, and arrogant at worst. > > Knowing some of the other people on this list its hard to describe all > of the people who aren't jumping on the bandwagon as reactionaries who > just use the status quo... we've got JINI people on this list, > describing Jini people as "status quo" is like describing Ry Cooder as > Status Quo. > >> You're viewing REST >> as just another sustaining innovation, but for enterprise >> integration, it isn't a sustaining innovation, but it's a >> potentially >> disruptive one. Go read the book. > > Read the book, read the REST paper, and I have to say if the REST > crowd are thinking that REST is a truly disruptive technology then its > time to stop drinking the kool-aid and actually take a look at what we > are talking about. > > REST shifts XML docs from A to B, it provides a way for a dynamic > interface to be communicated to a user. The creates a complex > programming model that requires significant upfront investment for a > purported ROI at a "later date". There is not ONE single thing that > REST is talking about that hasn't been done previously, and the > problem sphere of REST is one of the least critical part of any > successful distributed system (namely the execution context). To > cause "disruption" on what is an infrastructural element is highly > unlikely, what is much more likely is disruption that uses the > existing fabric and provides... NEW facilities over it, e.g. VOIP. > And before you leap on that and go "that is what REST does it uses > HTTP and....." no it doesn't it does the same thing over the same > internet, it just uses a different base carrier than previous > generations or the same carrier but with less abstraction. VOIP took > an existing market (telephones) and transported it into a different > medium (IP), thus changing the way that the existing market worked. > > REST is _not_ a silver bullet, remote invocation is _not_ a challenge > and REST is only disruptive in that it stops people looking for the > true disruption which will come when we consider remote invocation a > true commodity. > > > >> >> --steve >> > > > > Yahoo! Groups Links > > > [EMAIL PROTECTED] >
