I suggest you ...

Synchronous networking support

The Silverlight networking support is crippled by not supporting synchronous access.

There are many cases where the synchronous API is more convenient than the existing synchronous one. How much sense does it make to use worker threads if the network access is not synchronous?

XmlHttpRequest supports synchronous access and it is useful in many cases, unfortunately it does not support cross-domain access. Why is Silverlight less capable?

One clear case that requires synchronous networking is issuing a web service call when the page is closed / unloaded. Any asynchronous call in this case will be cancelled by Silverlight or the browser.

221 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Stefan GalStefan Gal shared this idea  ·   ·  Admin →

    8 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • LuckyWolf19LuckyWolf19 commented  · 

        I totally agree with this! For line of business apps, my users need to have all controls loaded from WCF prior to doing any data entry. Current work arounds require a lot of additional code to support. Lack of this service also prevents library like classes as we always have to create handlers and pass bake to calling class. Again more code than needed. If WPF has this and is for LOB apps, why not Silverlight?

        Scott Peal
        Chief Global Architect
        Company Automation LLC

      • herzmeister der weltenherzmeister der welten commented  · 

        First at least stop enforcing us to use async patterns for web service proxies. Perhaps we already are on a non-UI thread when calling a method.

        Using MVVM, a much more natural way of programming is possible, see this pattern: http://www.codeproject.com/KB/silverlight/Mtvt.aspx

        It makes clear that it's easy to employ a sync-like programming model while the async stuff is abstracted away under the hood. It's only Silverlight's framework restrictions that are in the way.

      • h.eskandarih.eskandari commented  · 

        Been using SL4 in a LoB app for quite a while now and there are a LOT that can go wrong when using async calls. Currently we do async calls to fetch the data and block the UI using a overlay but other than making no sense (why would you block the UI when you fetch data asyncronously, right?) it all just leads to writing more code which is cluttered with async stuff we really do not use. Also from testing perspective, generated proxy interface is a nightmare to do testing with.

      • snortsnort commented  · 

        It would be great to extend this to the Socket class too, technical limitations permitting.

      • JiaxiangJiaxiang commented  · 

        It will be nice if the users can choose sync / async networking download.

        Thanks

      • dullesteamdullesteam commented  · 

        Well said mepfusto.

        The case where a web service needs to be called as the page is unloaded is still not resolved. That must be synchronous, even if it is in the UI thread.

        It is funny how you guys know better than the application developers what is 'right'. Why don't you let the people developing the applications decide what API is the right one for them? Wpf & XmlHttpRequest support both network access models and it is the right thing to do.

      • mepfusomepfuso commented  · 

        At least HTTP requests shouldn't be executed on the UI thread (or be separated "virtually" if not possible), so that we can do something like WaitHandle.WaitOne() in a non-UI communication or calculation thread without freezing Silverlight.

        Most of us already do async helper objects to store communication state so we can do MyService.GetLunch().OnSuccess(result => ...).OnError(exc => ...).

        But these async helper objects shouldn't bleed into the entity model design.

        I know we should get "used to" asynchronous programming, but not in a way where we are forced to do spaghetti code in the UI again.

        Ideally, async processing should happen in the background, and all properties should be considered as declarative, so that I can write

        myTextBox.Text = mySteamboat.Captain.Clothing.Hat.Color.Name; // sub properties are being lazy-loaded

        without handling zillions of events or without that {Binding} syntax.

        This would then be a modern, transparent, thoroughly implemented async concept without being just half-baked like it is today.

      • Jack BondJack Bond commented  · 

        You certainly should be able to do this using the client network stack.

        How about this as a compromise; for those concerned about user experience:

        Raise an exception if a sync call is performed on the UI thread (trivial to do)
        Raise an exception if a sync call is performed on the browser network stack (as opposed to the client stack)

      Feedback and Knowledge Base