User talk:Zha Ewry/AWG: Desiderata for evaluating the proposed design
Separation of concerns
I just added a couple of considerations to this section, and then realized that this was probably inappropriate because these are your desiderata, and not AWG ones (yet). Should I delete them and wait until they are merged with project pages, or would you agree to keep the new considerations as yours? --Morgaine Dinova 04:56, 27 September 2007 (PDT)
Well I put them forward as mine, for discussion. We don't have a mechanism to end up with "These items represent a consensus." yet. We clearly will need one. Feel free to add your thoughts.. and we can re-label the page a little.
-- Zha 9/27/2007
Plug and proxy models
It's worth mentioning that the matter of proxies (and caches, which are strongly related) is very important on the distribution/scalability front as well. When a private world machine or small external grid attaches to a large enterprise grid like that of LL, the influx of visitors from large to small would almost always overwhelm the small site in the absence of a proxy and caching mechanism within the large site, as a natural consequence of their relative scales.
Consequently, the concept of proxy needs to be expanded substantially for a scalable distributed world system, ie. to cache external state and to handle much of the object-related traffic that would otherwise all be funnelled out to the small system on every access. Without this, large systems will never be able to connect to small ones in a manner that would satisfy their residents, because the small systems would always be "Slashdotted", to coin a phrase. --Morgaine Dinova 03:34, 24 September 2007 (PDT)
Although each attached grid would naturally be authoritative for its own contained objects, the degree of passthrough of object transactions needs to be a tunable parameter to cater for the disparity in sizes. For example a world on a laptop might receive transactions at only 1/1000th the rate at which its objects held within the caching proxy are accessed on the large grid to which it is attached. A rough analogy with the DNS system and also with transparent web proxies might help visualize the kind of relationships required in this area for scalability in a distributed system. --Morgaine Dinova 03:52, 24 September 2007 (PDT)
After the group chat yesterday, I felt the emphasis on a cached proxy layer has not been significant enough. That feel grows out of the suggestion that the reverse proxy has not been seen as an essential part of the architecture. That may be true if one looks at a plain proxy as only to forward services, but that would be the forward proxy; hence, there is a big difference between forward and reverse proxies. A reverse proxy can actually be an end-point to create an authoritative response instead of just forward the request. Strategically placed reverse proxies create potential end-points before potential traffic bottlenecks. How the actual reverse proxy is implemented is not the architecture side, but the strategically defined placement and the potential separation (created by the end-point) from the grid is key to the architecture. These end-points act like mini-grids where at worst the main grid must forward states (by a poll) to the reverse proxy to keep the cache updated, which allows further authoritative responses by the reverse proxy to the viewer. Now, if this is clear enough, you'll see how reverse proxies can be added now except that it still needs the authentication (WVA) layer. This strategic placement also justifies that other REST/physics related use case (and like) are actually implementation and not architectural. You should see that REST/cHTTP becomes more architectural. (mileage may vary some) Dzonatas Sol 20:12, 11 October 2007 (PDT)