[sldev] [ARCH] Render unto Caesar the things that are Caesar's

[Tao Takashi]

Hi!

Good that somebody thinks about workitem 2 which is about alternative
setups to the proposed architecture :-)


I'm not sure what the Hosts are in the diagrams, but my interpretation
> is that they are temporary instances, "virtual" virtual worlds.  The
> information about an avatar is kept in the Stores, and when that avatar
> logs on, an instance of the avatar is created on an Avatar Host.  The
> information about a region is kept in the Stores, and when someone
> visits it, an instance is created on a Region Host.



As Gigs said, it's an Agent Host and according to Mark they are supposed to
store an
agent's session which is e.g. status of the agent, things about presence
information and
so on.

It's not clear from the charts exactly what is in an Avatar Host, so let
> me suggest that first it should contain an instance of the avatar mesh.



I am not sure it will. I think the mesh and all the things an avatar is made
up of will
be transferred to the region for simulating it. Mark also said that the
Region host will
be basically the same what a simulator is right now. This would mean that
the agent
host probably does not have that much to do. It's mostly there to handle the
login session
of the user. In my understanding it might be responsible for changing
profile, handling
inventory transactions from and to regions and other agents etc. I think it
is even open
how these transactions to other agents may occur, whether it's through the
region or
directly from agent host to agent host or maybe via the viewer.

An avatar's inventory and all processing of the inventory would be
> handled by the Avatar Stores.


Again, it's Agent Stores but from my understanding you are right, it stores
e.g. profile
information and assets for the avatar.

A region host would contain instances of all objects owned by the
> region, but the ownership would be handled by the Region Stores.


I think this is right although maybe "owned" is the wrong word. It will
contain the
region's inventory, assets copied over from agent hosts e.g. when rezzing
something in-world. The Owner of course is still the agent but I think you
mean the right thing.



> The diagrams don't consider multiple viewers attached to a Region Host,
> but let's consider how viewers get information about other avatars.  In
> the current SL architecture, all the information about all of the
> avatars is on the sim (region host) and all connections are through the
> sim.  When an avatar moves across regions, his information is handed off
> from sim to sim.  And because of this, we are limited to about a hundred
> avatars per sim.
>
> So the new architecture has Avatar Hosts to keep track of the avatar
> information, and viewers get information from the Avatar Hosts.  So if
> my avatar is in the Region and your avatar is in the Region, we both get
> information from the Region Host and we share information from our
> respective Avatar Hosts.  And if we would like to be able to see across
> regions, we need to contact all of those other Avatar Hosts.  That's a
> lot of very dispersed connections.



I think it's mostly handled by the region host. The region host knows where
each agent is
and should also have the avatar information at hand. Whether the region host
is actually 2
boxes, one for just the agent information and one for region stuff should
not matter in the
architecture. It even can be a cluster of 100 boxes. The only important
thing here is the
interface. I think one should think of all these more of black boxes. I also
wonder if we
shouldn't think about the whole domains more as black boxes. They just have
different interfaces
for either static information and dynamic information (services and hosts).


Which brings me to my alternate partitioning of the tasks:  The Avatar
> Hosts should be in the same domain as the Region Hosts.



As said, this will probably be one box or many depending on how you set this
up.
Actually you would have an additional host here, the avatar host, which is
not the
same as the agent host.
But Linden Lab might correct us here what they think each component handles.
Of course you are right that these things should be close together.


> Right now we have huge central Stores, but we really know that objects
> belong either to an avatar or a region, so the Stores can be very small
> and very distributed with connectivity only to the relevant Avatar Hosts
> and Region Hosts.  Transactions with the Stores would be through the
> Stores servers.  There would be no "push" transactions to the Stores,
> they would all be "pull" transactions by those who are authenticated to
> the Stores servers.  So the Stores could even be simple Apache web
> servers.  The Stores could "push" to the Hosts or the Hosts could "pull"
> but nothing is permanent on the Hosts.


Well, this is more implementation details but I think basically that's
correct. The
protocol will be REST mostly anyway. Whether it's push or pull needs to be
seen,
maybe the terms are also misleading, I guess it will get clearer once some
sequence diagrams or transaction descriptions between region host and agent
host
are done. But there needs to be some means of course to transfer an asset
from
region to agent and the other way round (and from agent to agent).

-- Tao



-- 
taotakashi at gmail.com
http://taotakashi.wordpress.com
http://worldofsl.com

RL: Christian Scholz, cs at comlounge.net
http://mrtopf.de

http://comlounge.net
http://comlounge.tv
http://mrtopf.tv
http://dev.comlounge.net
IRC: MrTopf/Tao_T
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070918/e25150d4/attachment-0001.htm