On 18/12/06, Steve Vinoski <[EMAIL PROTECTED]> wrote: > > > > > > > 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.
Fair enough, glad to be spectacularly wrong is so few words. I'll still bet heavily that REST won't advance the lot of IT systems beyond the "now" accept for those who really desire to understand the shifting of the documents. > > (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] > > > > > >
