Re: Push to web clients
Not sure about the server side 2012 requirements but signalr drops to polling iframes etc if websockets are not available I think. On Wednesday, 8 April 2015, Greg Keogh g...@mira.net wrote: Folks, our ASP.NET app can submit a job to the server for processing which can take up to a minute or so. We've been looking at ways the client can see progress on the server-side: * AJAX script could poll at intervals by calling a web service method * A kit like SignalR could push notifications to the client. SignalR is of course the most elegant and attractive option, but HERE http://www.asp.net/signalr/overview/getting-started/supported-platforms I see this note about using WebSockets as the preferred transport: *... Note that for SignalR to use WebSockets, Windows Server 2012 or Windows 8 is required (WebSocket can be used on Windows Azure Web Sites, as long as the site's .NET framework version is set to 4.5, and Web Sockets is enabled in the site's Configuration page).* We don't have a 2012 server or Win8 dev machine at the moment. Using Azure is a future possibility but we'd have to investigate how to deploy a Kentico http://www.kentico.com/ site to Azure. So there are many irritating overlapping issues to get SignalR working. Any general comments on this web server push idea this would be welcome. *Greg K*
Re: Push to web clients
SignalR will still work without WebSockets, it will fall back to long polling I believe. I created the demo app that broadcasts a fake stock ticker. I ran it locally on my Win7 dev machine, then I deployed it to Azure. Fiddler traffic shows that messages are very similar for each scenario and I can see signalr in the messages as well as longPolling. I expected to see different sorts of traffic because it thought it would fallback on my local machine, however they both look roughly the same. Oh well, at least I have proof it works in some mystical way. The code and scripts that make the demo work are obtuse, cryptic, verbose and fragile, and you'd have to take a bit of time to study how it works and get a comfortable feel for it. This confirms my distaste for writing anything with JavaScript involved ... it's the joke of the century. Once day when I'm an old head-in-a-jar and someone has finally made the web function properly, we'll look back and laugh and say I can't believe we made that junk work!. *Greg K*
Re: Push to web clients
Don't even get me started on javascript. I feel just as dirty using javascript as I did with silverlight version 1. God save us On Wednesday, 8 April 2015, Greg Keogh g...@mira.net wrote: SignalR will still work without WebSockets, it will fall back to long polling I believe. I created the demo app that broadcasts a fake stock ticker. I ran it locally on my Win7 dev machine, then I deployed it to Azure. Fiddler traffic shows that messages are very similar for each scenario and I can see signalr in the messages as well as longPolling. I expected to see different sorts of traffic because it thought it would fallback on my local machine, however they both look roughly the same. Oh well, at least I have proof it works in some mystical way. The code and scripts that make the demo work are obtuse, cryptic, verbose and fragile, and you'd have to take a bit of time to study how it works and get a comfortable feel for it. This confirms my distaste for writing anything with JavaScript involved ... it's the joke of the century. Once day when I'm an old head-in-a-jar and someone has finally made the web function properly, we'll look back and laugh and say I can't believe we made that junk work!. *Greg K*
Re: Push to web clients
SignalR will still work without WebSockets, it will fall back to long polling I believe. Craig On Wed, Apr 8, 2015 at 10:50 AM, Greg Keogh g...@mira.net wrote: Folks, our ASP.NET app can submit a job to the server for processing which can take up to a minute or so. We've been looking at ways the client can see progress on the server-side: * AJAX script could poll at intervals by calling a web service method * A kit like SignalR could push notifications to the client. SignalR is of course the most elegant and attractive option, but HERE http://www.asp.net/signalr/overview/getting-started/supported-platforms I see this note about using WebSockets as the preferred transport: *... Note that for SignalR to use WebSockets, Windows Server 2012 or Windows 8 is required (WebSocket can be used on Windows Azure Web Sites, as long as the site's .NET framework version is set to 4.5, and Web Sockets is enabled in the site's Configuration page).* We don't have a 2012 server or Win8 dev machine at the moment. Using Azure is a future possibility but we'd have to investigate how to deploy a Kentico http://www.kentico.com/ site to Azure. So there are many irritating overlapping issues to get SignalR working. Any general comments on this web server push idea this would be welcome. *Greg K*
Re: Push to web clients
http://macleodsawyer.com/2015/03/06/nine-truths-computer-programmers-know-that-most-people-dont/ You've pretty much described Fact #1. Everything is hacked together with duct tape and coat hangers. :) That's the beauty of it all. The power of Javascript is that you *can* hack it together. Does it mean you should? We'll leave that discussion for another lunch time. On Wed, Apr 8, 2015 at 10:17 AM, Greg Keogh g...@mira.net wrote: SignalR will still work without WebSockets, it will fall back to long polling I believe. I created the demo app that broadcasts a fake stock ticker. I ran it locally on my Win7 dev machine, then I deployed it to Azure. Fiddler traffic shows that messages are very similar for each scenario and I can see signalr in the messages as well as longPolling. I expected to see different sorts of traffic because it thought it would fallback on my local machine, however they both look roughly the same. Oh well, at least I have proof it works in some mystical way. The code and scripts that make the demo work are obtuse, cryptic, verbose and fragile, and you'd have to take a bit of time to study how it works and get a comfortable feel for it. This confirms my distaste for writing anything with JavaScript involved ... it's the joke of the century. Once day when I'm an old head-in-a-jar and someone has finally made the web function properly, we'll look back and laugh and say I can't believe we made that junk work!. *Greg K*
