"it is simply not possible to use HTTP PUT or DELETE methods, a problem that leads to hacks like HTTP POSTs that delete data, breaking the HTTP specification. This is not the fault of Silverlight, but it is unfortunate."

And why wouldn't it be the very fault of Silverlight, please? Would it by any chance be the standard's fault? Or the navigator's fault, for not being compliant with the plug-in? Once again, they went the easy way, breaking the standards that happened to stand in the way.

Next time I drive down a one-way street the wrong way, I hope I'll get away with it by telling the pigs "not my fault, as this path is much shorter" or "not my fault, as the way I'm going should be the allowed one".

"Silverlight at a disadvantage to Flash for downloading large amounts of data, since Flash can use Adobe's efficient ActionScript Message Format"

AMF3 is an open and documented format, MS could use it they wanted too... but then they'd not be locking you to the expensive .Net tool sets...

"Apparently it is simply not possible to use HTTP PUT or DELETE methods, a problem that leads to hacks like HTTP POSTs that delete data, breaking the HTTP specification. This is not the fault of Silverlight, but it is unfortunate. For similar reasons, there is no access to SOAP fault messages."

"And why wouldn't it be the very fault of Silverlight, please?..."

As in, it's not the fault of Silverlight that Silverlight can't use these methods, rather than it's not the fault of Silverlight that it had to break the standard and do it anyway...

That's how I read that anyway..

The issue is that any plugin only has access to what comes over the wire to the extent that the browser's plugin API exposes it. This is only a subset of what actually comes over the wire, hence these limitations. The workaround would be for the plug-in to bypass the browser's networking stack, but that would cause other problems, like needing a separate login.

Tim

Carl: OK, that's a good point. But the original sentence is, at least, suspiciously ambivalent.

Tim: I know that. Plus, it's stated in the article.

" but that would cause other problems, like needing a separate login."

OK, so better break the standard than figure out a way to login separately? That was exactly the point of my first comment. They are lazy standard-breaking morons. Period.