Advanced Forum Search Results
-
>>Please no...unless they can work out a way to do it without hanging the browser
Just let us call sync on background threads.
If they are really so scared that lousy programmers will block the UI with service calls, they can disallow sync calls on the UI thread. As long as we get *some* way of performing sync calls in background ...
-
>In that case shouldn't be better implement full WPF hosted inside the browser?
No, that would require that all clients had .Net 3.5 on their computers.
-
>You are using WS as RPC: ok for LAN and low latency networks but not a good idea for high latency networks (Internet).
I agree. The point is that our application will always run on a LAN. We want to use SL to get all the browser advantages (easy rollout, centralized management, ...).
-
> Bottom line is the same with less code with SL.
Not.
Try doing this in SL (super simple example, real life might be a lot more complex). And btw., this code will not block the UI as it is running in a background thread.
int BackgroundCalcMethod(){
int input = ServiceA.GetInput();
if(count > ...
-
> Synchronous calls in very latency network (Internet) isn't wise.
After writing tons of successful synchronous C/S code (using threading), I strongly disagree with that statement. The combination of threading and (background) synchronous communication yields the best solutions in a lot of cases. Likewise, asynchronous communication might ...
-
Actually, this is a C/S app that always run on a local network with good response times. Currently, it runs just fine in a browser and a SL version should perform no worse.
After porting we would start optimizing the user experience, but we simply do not have the resources to re-architect the whole thing.
-
..and try converting a large project half-way through when you realize you need to do everything async... what a nightmare.
Exactly! We already have a very large AJAX application that we would like to port (not rewrite) to Silverlight. To do that with async will be a nightmare.
If we had to rewrite the app from scratch, we could probably do ...
-
Thank you for sharing.
I guess we will have to make do with "hacks" like this until synchronous communication (hopefully) returns.
Thanks again.
-
Here's a comment (originally posted on another blog)
We have a lot of code like this (very large app):
object Method1{
int result = CallServiceA();
if(result > 42){
return CallServiceB()
}
else{
return CallServiceC()
}
}
object Method2{
int ...
-
[copy of comment made elsewhere]
I think that it is huge mistake to leave out synchronous communications.
If they are really afraid of people locking up the browser, they could at least support it in background threads. You can lock up the main thread in hundreds of ways (while(true){}) so why this fixation on server calls.
My ...