tag:blogger.com,1999:blog-6810771.post3745597021276282691..comments2009-05-02T11:38:19.906-07:00Ashish Shettynoreply@blogger.comBlogger13125tag:blogger.com,1999:blog-6810771.post-13871272446847730212008-09-10T10:28:00.000-07:002008-09-10T10:28:00.000-07:00Hey ashish very good blog and good technical knowledge by u .<BR/><BR/>I am really very much amazed with your technology understanding <BR/><BR/>I have also implemented my project as a social networking website <BR/>in java jsp<BR/>https://www.fabgabs.com <BR/>Keep it up with ur projects <BR/>we young indians will make every indians proudSanjanahttp://www.blogger.com/profile/08162739356193743397noreply@blogger.comtag:blogger.com,1999:blog-6810771.post-30244840359999845032008-07-31T21:17:00.000-07:002008-07-31T21:17:00.000-07:00I've learnt to accept the async world we now live in. THOU i dare say that it will only get worse in a couple in a years time when we have parallelism engrained in our apps. We as humans don't naturally think this way thats why it will cause alot of pain for most developers. <BR/><BR/>Personally Ive encountered numerous situations that have required a sync model and have had to build my own queue mechanism to manage async calls. In time a common set of patterns and frameworks will arrive that will make this easier BUT for now I've had to write alot of spagetti code to fake Sync style calls. <BR/><BR/>If all the Midori rumours surfacing on the web are true then I can understand why MS want's all of us to go async.advertboyhttp://advertboy.wordpress.com/noreply@blogger.comtag:blogger.com,1999:blog-6810771.post-80835656460705681572008-07-27T04:53:00.000-07:002008-07-27T04:53:00.000-07:00While I can see that some people think it's a bit too paternalistic to make the choice for the developer, I like the fact that you push for the async model. I come from a webprogramming background and I only have limited experience of the async model in ajax apps, so yes, it was at first a hindrance for me to make my requests async. It held my progress back for like 30 minutes until I got the hang of it...Karlnoreply@blogger.comtag:blogger.com,1999:blog-6810771.post-43759708259988211852008-07-25T05:47:00.000-07:002008-07-25T05:47:00.000-07:00i like events, especially those party events with a lot of girls :D<BR/>Events are really revolution! Gopd bless events creatorAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-6810771.post-4763923076263656902008-07-24T15:14:00.000-07:002008-07-24T15:14:00.000-07:00From a business persective, the predominantly async model is a significant hindrance, as it may result in significantly increased development costs and delivery delays. When in question, it's best to let developers determine the most effective approach given their needs rather than imposing your view of what's best for them.Phil Jacobsenhttp://www.timescope.comnoreply@blogger.comtag:blogger.com,1999:blog-6810771.post-57136323245232261712008-07-24T12:17:00.000-07:002008-07-24T12:17:00.000-07:00Great. According to a couple Microsoft posters on the silverlight.net forums, the switch to async only was required by the various browser plug-in APIs, and NOT a "let's show them a better way" or "most developers are too stupid to handle sync programming properly, so let's take it away from them". If this wasn't in fact a technical decision, then it was a <B>horribly</B> stupid one.<BR/><BR/>So, short answer, yes, this has been a hindrance. I'm not sure how you see this as "giving fish and fishing lessons", you haven't given anything (quite the opposite), and you've taught nothing. You've stripped skilled developers of a vital tool, and attempted to tailor the platform to clueless dopes who ultimately try and simulate sync behavoir by doing stuff like:<BR/><BR/>while(SomeFlagHasntBeenSet)<BR/>{<BR/><BR/>}<BR/><BR/>So what really did drive this decision? The lack of the Invoke method on the Dispatcher object makes me wonder. And if this in fact a dumbing down of the platform, could you remove the int type, as well as all the other built in types? You never know, someone might attempt to calculate the last digit of pi, which will block the UI and other tabs. For that matter, get rid of for, foreach, and while loops, because those could clearly be misused. And please remove the System.Threading namespace, because someone might create lots of threads, which might bog down system performance. While you're in there, might as well gut out the new keyword, because someone might allocate lots of objects, and drain system memory. Just to be extra safe, please make event handlers such as button_click async as well, you never know what someone could do in an event handler. You also clearly need to disable access to the HTML dom, because someone could call the sync methods on the native XmlHttp object. No reason to have GC.Collect(), that's misused virtually 100% of the time anyway. Now THATS the platform we need. A super dumbed down POS that attempts to prevent morons from doing moronic things. Oh wait, we've already got one of those, I think it's called Javascript.<BR/><BR/>When they announced Silverlight 1.1 Alpha with the .net framework, I was really excited. I thought, wow, I can <B>FINALLY</B> do real programming. I would no longer be crippled by stupid annoying constraints or waste hours and hours working around retarded browser incompatibilities. Silverlight was going to be a REAL platform. Unfortunately, now it's looking like you guys are starting to dumb it down so that the average html weenie can't hurt himself.Jack Bondnoreply@blogger.comtag:blogger.com,1999:blog-6810771.post-74092465992285856112008-07-24T09:30:00.000-07:002008-07-24T09:30:00.000-07:00I am an old-time OS internals (and distrirbuted systems) programmer so it is not an "async" model that is difficult.<BR/><BR/>But what is hard is the lack of documetation about what runs on the main UI thread and what does not.<BR/><BR/>It seems that I don't need to use the Dispatcher for mouse events, keyboard events.<BR/><BR/>It seems that I can have multiple instances of a storyboard running that is modifiying Framework elements in parallel. <BR/><BR/>So other than webclient calls, what does not run on the UI thread?<BR/>Or am I playing fast and loose here?DrYSGhttp://www.blogger.com/profile/08796890854969735807noreply@blogger.comtag:blogger.com,1999:blog-6810771.post-18835190968959153502008-07-24T09:06:00.000-07:002008-07-24T09:06:00.000-07:00*Definitely* the right move in my opinion. <BR/><BR/>Anyone doing AJAX development is already familiar with the async patterns due to the fact that this is the way XMLHTTP works. Therefore it shouldn't present too steep a learning curve for those developers who are looking to step into the Silverlight world.Drew Marshhttp://blog.hackedbrain.comnoreply@blogger.comtag:blogger.com,1999:blog-6810771.post-90903259855424482402008-07-24T09:05:00.000-07:002008-07-24T09:05:00.000-07:00I love the async model! :-)Bryannoreply@blogger.comtag:blogger.com,1999:blog-6810771.post-91180514203528172452008-07-24T08:12:00.000-07:002008-07-24T08:12:00.000-07:00All fine and dandy, but RIA generally needs a fast and efficient platform, and I am not sure wether Silverlight is really the platform for it anymore.<BR/><A HREF="http://www.dotnutshell.net" REL="nofollow"><BR/>Software Development Expert<BR/></A>ajmalhttp://www.blogger.com/profile/03561734384990798160noreply@blogger.comtag:blogger.com,1999:blog-6810771.post-76862668658447541962008-07-24T05:41:00.000-07:002008-07-24T05:41:00.000-07:00I also enjoy the event driven async model. I think this is the model that works best for a web-based UI platform. I think individuals will run into problems if they have two server calls that are dependent on each other. However, as you stated, its a learning process. Once you learn about it, it isn't a problem. <BR/><BR/>P.S. This post has made me think to add something to chapter 6 of Silverlight 2 in Action. Thanks!Chad Campbellhttp://www.blogger.com/profile/14366408349191032557noreply@blogger.comtag:blogger.com,1999:blog-6810771.post-15582787898490559062008-07-24T01:24:00.000-07:002008-07-24T01:24:00.000-07:00I really like the event driven async model, as it gives me greater control over when to do what in code. The whole "event thingy" is like evolution. Until you get the greatness of it, you dont really get it. I have even begun to fire my own events now :)Rasmus Lorentzennoreply@blogger.comtag:blogger.com,1999:blog-6810771.post-41323022956042315502008-07-23T22:32:00.000-07:002008-07-23T22:32:00.000-07:00Yes, the async. model work to robust the user interaction.Codebasedhttp://www.blogger.com/profile/04586466357507693704noreply@blogger.com