>> that may well out last any other area.
Indeed. I am not presupposing that @Home offer web-based desktop service in a "closely coupled" way ... by acquisition, internal development, or licensing an existing system to run closely-bound to the @Home wires and boxes.
There are lots of ways, technically and organizationally, that web-based service might get to the user via @Home.
Some might vote to take the low-ground ... the backbone position.
The counter-argument, however, has some interesting meat.
It goes like this. @Home should closely-couple the web-based desktop service to their infrastructure because it uniquely solves QoS issues that are a major challenge to these services. In other words, @Home can uniquely enable thin-client, fat-server applications in general.
This argument pulls out a key value of @Home's infrastructure ... they can offer scaleable QoS to content providers ... and web-based applications are a specific example of content providers who benefit from enhanced QoS.
Ahhaha, Frank? Can you comment on the ability of @Home technology to deploy web processes closer to the user? Can @Home generically deliver distributed server capacity?
Notice how web-based desktops and other apps challenge the web-page caching model ... they would tend to thrash net caches pretty well ... they want the server-side processes out as close to the user as possible.
Can @Home accomodate this?
If so, then the low-ground, backbone model is strengthened.
Based on my own technical expertise (?) I think it's simpler in the short run to deploy web-desktop server boxes to @Home POPs as unique entities ... this implies a certain business relationship more intimate than the backbone model allows. |
