The reason why there are no synchronous calls in silverlight is (I
believe) because you can easily deadlock the plugin by attempting a
synchronous call when using the browser http stack. For the web
request to be completed, the browser has to be able to iterate and if
a plugin is blocking,
Atsushi,
I doubt I have the required knowledge to implement what you said
right now. As I have said before, I'm still getting familiar with WCF
architeture. I hope I can contribute to your efforts soon.
On Tue, Jul 6, 2010 at 1:08 AM, Atsushi Eno
atsushi...@veritas-vos-liberabit.com wrote:
Alan,
I think I read that explanation before, but responsive UI can be
achieved using background threads, so I don't think silverlight should
force programmers to use the async pattern.
It seems that the async pattern is forced at the socket level, as
shown in
Hi Atsushi,
I have started messing with WCF last week but I'm very interested in
learning, If you need help with anything just send me a message.
Also, today I'm starting to develop an http binding/channel to allow
REST syncronous programming of WCF Services/Clients(compatible with
Hello Thiago,
Thanks, there's a lot of major and minor missing functionalities all
around. Our class status
describes large part of those missing stuff (primarily in
System.ServiceModel.dll):
http://go-mono.com/status/
Right now we have no plan to build mono specific WCF libraries. IMO
Hi,
Right, thanks for the analysis, that should be fixed, and I have an
idea. Though I am now rewriting ASP.NET channel support based on our new
HTTP (non-ASP.NET) channel stack and it does not use the code path you
mentioned, I'd rather finish the rewrite first and then fix the actual
issue.
Hi,
I'm hosting a WCF service using asp.net/mono from trunk (r159644)
but encountered a problem when accessing the service from a virtual
machine :
The argument HTTP context did not match any of the registered
listener manager (could be mismatch in URL, method etc.)
