Whatever. I'm right, because I've written code that does what Web services people say is impossible. It's not like I'm going to wake up and realize that I didn't write that code.
I've also spent much of the past 5 years studying very large scale systems in extreme detail. Before that, I was a CORBA wiz, so I'm well aware of pros and cons of both architectural styles.
I choose REST because it's superior to Web services in practically every way that is important to large scale systems. Moreover, I reject Web services, because it fails to pass the single most critical litmus test for large scale systems; it's not late bound (i.e. integration complexity is necessarily worse than O(N)).
Re:RPC is OLD. XML is LAME. Why waste time ?
on
ESR On XML-RPC
·
· Score: 1
Amen. While XML by itself is fine, RPC just sucks for moving it.
The last thing the world needs is a billion different interfaces (RPC APIs) to our software and information. What we need instead is a common generic messaging/tuple-space interface. Luckily we've already got that in HTTP. I wish more people understood that, especially smart guys like Dave Winer.
High speed wireless doesn't matter. I'm not going to be downloading Quake demos or using streaming video on a typical PDA. I don't need high speed. Low latency is much more important... but still not a big deal.
PDAs won't replace PCs, but they will complement them.
While I can't play Quake on a PDA, I can carry around my player profile and configuration on one.
While I can't view PDF documents on a PDA, I can beam it (IR, Bluetooth, whatever) to a local printer.
While I can't watch movies on one, I can use my PDA to command my TV to access some MPG URL, and carry that URL around on it.
> A lot of stuff that's in HTML is not legal in XML, like the IMG tag and the OPTION tag: Sure it is, in well formed XML documents. Just don't expect it to be understood by any other XML-based-language processor. Transcoding is a good idea, but the hard work isn't in the transcoding infrastructure, it's in the style sheets. Also, there's several commercial offerings in this space that have been around for a while; Spyglass Prism OnlineAnywhere (acquired by Yahoo) Proxynet (acquired by Puma) Argogroup Actigate MB
First of all, Jini has nothing to do with RMI. The dependancy consists solely of the use of java.rmi.RemoteException, which encapsulates entirely generic network exception semantics (and so could have been in an entirely separate package).
Secondly, how the heck is a 40K VM too big? http://java.sun.com/products/kvm
(BTW, I work for Sun, but I'm speaking for myself)
> Anyway, open protocols are good for the Internet. Efforts to promote open protocols should be supported regardless of the perceived motives of the participants.
Blah blah blah. Care to respond to his points, rather than spewing religious dogma? What is so magical about open protocols that somehow make them immune to critical reasoning about how, when, and if to support them?
Any dummy can throw a map system into a car with a UI on it. How many get the map realtime over the net via HTTP by tying their GPS coords into a CGI request?
And how many decode the car's data bus and push that data over UDP/IP?
Slashdot Mirror
Whatever. I'm right, because I've written code that does what Web services people say is impossible. It's not like I'm going to wake up and realize that I didn't write that code.
I've also spent much of the past 5 years studying very large scale systems in extreme detail. Before that, I was a CORBA wiz, so I'm well aware of pros and cons of both architectural styles.
I choose REST because it's superior to Web services in practically every way that is important to large scale systems. Moreover, I reject Web services, because it fails to pass the single most critical litmus test for large scale systems; it's not late bound (i.e. integration complexity is necessarily worse than O(N)).
Amen. While XML by itself is fine, RPC just sucks for moving it.
The last thing the world needs is a billion different interfaces (RPC APIs) to our software and information. What we need instead is a common generic messaging/tuple-space interface. Luckily we've already got that in HTTP. I wish more people understood that, especially smart guys like Dave Winer.
High speed wireless doesn't matter. I'm not going to be downloading Quake demos or using streaming video on a typical PDA. I don't need high speed. Low latency is much more important ... but still not a big deal.
PDAs won't replace PCs, but they will complement them.
While I can't play Quake on a PDA, I can carry around my player profile and configuration on one.
While I can't view PDF documents on a PDA, I can beam it (IR, Bluetooth, whatever) to a local printer.
While I can't watch movies on one, I can use my PDA to command my TV to access some MPG URL, and carry that URL around on it.
Think different.
MB
> A lot of stuff that's in HTML is not legal in XML, like the IMG tag and the OPTION tag: Sure it is, in well formed XML documents. Just don't expect it to be understood by any other XML-based-language processor. Transcoding is a good idea, but the hard work isn't in the transcoding infrastructure, it's in the style sheets. Also, there's several commercial offerings in this space that have been around for a while; Spyglass Prism OnlineAnywhere (acquired by Yahoo) Proxynet (acquired by Puma) Argogroup Actigate MB
First of all, Jini has nothing to do with RMI. The dependancy consists solely of the use of java.rmi.RemoteException, which encapsulates entirely generic network exception semantics (and so could have been in an entirely separate package).
Secondly, how the heck is a 40K VM too big?
http://java.sun.com/products/kvm
(BTW, I work for Sun, but I'm speaking for myself)
> Anyway, open protocols are good for the Internet. Efforts to promote open protocols should be supported regardless of the perceived motives of the participants.
Blah blah blah. Care to respond to his points, rather than spewing religious dogma? What is so magical about open protocols that somehow make them immune to critical reasoning about how, when, and if to support them?
MB
Ah, but do they have a *network* in the car?
Any dummy can throw a map system into a car
with a UI on it. How many get the map
realtime over the net via HTTP by tying their
GPS coords into a CGI request?
And how many decode the car's data bus and
push that data over UDP/IP?
MB (who worked on the car)