Erik Meijer: Volta - Wrapping the Cloud with .NET - Part 2

"there is a lot of pain out there". priceless

It's a nice idea to be able to refactor an application from a clients point of view into multiple tiers and platforms.

Is there some set of shared concepts for programming against both Silverlight and the browser? I'm not sure it makes that much sense, but that would make it seamless for code to run in either environment without needing to decide which. On the other hand, for it to make sense, it would have to offer some benefit in terms of flexible controls and effects that are not easily done in the pure browser environment alone.

One possible example of that may be the JS/DOM 3D engine. On the other hand, I can't believe anything non-trivial can be animated - generated perhaps, although it could heavily influence scrolling and reflow speed.

It's cool though.

There are also several 3D engines for Flash. I've toyed with one myself, but it used to be that they were quite slow and not really usable for anything non trivial. The faster runtime in Flash 9 may be improving that but probably the software rendering is still the bottleneck. For static rendering, it can be quite useful, though. Flash also has the ability to render to bitmaps, so you can do raytracing if you want to. That is, you *could*, but at a framerate not worth mentioning.

Can hardware accellerated 3D be embedded in the browser. If not, then why not? What are the challenges?

There is also the potential to have shared concepts for Silverlight and Flash. Obviously, they're very similar and have similar goals. But the question becomes: is it worth the effort. If you're already "going plugin", you might as well "go Silverlight" and forget Flash altogether.

This makes me wonder.  In this case, the browser is not really required at all (save the non-silverlight method).  Especially with silverlight, you don't really need the full brower, all you need is some window to use as a display container (ala winform).  And you don't really need html or http, as under the covers you could be stitching the layers together with WCF or something else.  Naturally the browser will remain important, but not required once the app loads.  Probably some interesting solutions down the road.  This also makes me wonder if the browser will just become a smart client container that just happens to also support the old-style html stuff. 

Thanks Erik.  Good stuff.  Thinking outside the box here.  It would seem a message passing style between layers (ala CCR like) could be both simple and solve a lot of problems under the covers.  Example:

[RunOn="client"]
class Client
{
   override void InMessage(Msg msg)
   {
        // Do stuff with msg.
   }
   override void SendMsg(Msg msg)
   {
       srv.Send(msg);
   }
}

[RunOn="srv1.abc.com", Processor=1, MaxTps=500]
class Srv
{
    override void InMessage(Msg msg)
    {
        // Do stuff with msg on the server.
        msg.Reply("ok");
    }
}

Now that we are in "msg" world, you can create thin version of SQL Broker between layers and get transaction support and ordering, etc.  Could also choose some other transport (wcf, http, etc), but not have to be concerned with the network layer.  The in/out queues would also make runtime debugging super easy as you could track the message flow around the in/out queues of the layers (with a management Tool or even in code such as unit tests, etc).  Essentially a common API call is like an implicit typed-message anyway, so this method is not that far out (once you get passed the learning hump) and has some interesting benefits.

Interesting approach What I'm wondering is if Volta uses ATLAS internally - or at least the ATLAS javascript runtime...

Look like JSC with some nice  html DOM api applied.

see JSC for IL to JS compiler which has been around for years.