Sign in / up

back to article Silverlight 2.0 data and web services explained

Microsoft Silverlight team member Eugene Osovetsky has explained to a packed Mix 08 session how Silverlight 2.0, released as beta on Wednesday, interacts with external data and web services. No surprise: the first thing we saw was based on the Windows Communication Foundation (WCF), Microsoft's universal .NET web services API …

COMMENTS

House rules Send corrections
This topic is closed for new posts.
  1. Pierre
    Dead Vulture

    Not their bloody fault, huh?

    "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".

    0 0
  2. Tom Chiverton

    AMF

    "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...

    0 0
  3. Carl
    Dead Vulture

    @Pierre

    "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..

    0 0
  4. Tim Anderson

    It's all about the networking stack

    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

    0 0
  5. Pierre

    @ everyone

    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.

    0 0
This topic is closed for new posts.