Second Life Wiki - User contributions [en]

File:SLCC Headshot.jpg

2010-07-13T20:08:22Z

Zha Ewry: headshot as of July 2010

headshot as of July 2010

User:Zha Ewry

2010-07-13T20:02:30Z

Zha Ewry: /* AWG musings */

Greetings, I'm an active participant in the [[Architecture Working Group]], an active resident, and an Employee of IBM. This does not not mean, I speak for IBM, except when I very specifically state that I'm doing so. Most of the time, I do not, although clearly my employment affects various of my opinions. If you want to talk to me, I'm in world most of the time, and catch e-mail for SL at zha.ewry@gmail.com.

Participant in [[Architecture Working Group]]. See [[User:Zha Ewry/comments on meeting 1]] for comments on this subject.

=== Visual Cue ===

=== AWG musings ===

This is a bucket where I toss some ideas I am exploring. Comments deeply appreciated, these are not public consensus pages.

:[[AWG: state melding exploration]]

:[[AWG: Core simulator exploration]]

:[[AWG: Cross Domain Trust issues]]

AW Groupies/Chat Logs/AWGroupies-2008-07-15

2008-07-15T19:11:01Z

Zha Ewry: New page: * a Trimble (0m), Goldie Katsu (5m), Siddhartha Fonda (5m), Saijanai Kuhn (8m), BlueWall Slade (9m) * [2008/07/15 9:28] Connecting to: in-world Voice Chat... * [200...

* a Trimble (0m), Goldie Katsu (5m), Siddhartha Fonda (5m), Saijanai Kuhn (8m), BlueWall Slade (9m)
* [2008/07/15 9:28] [[User:Connecting to|Connecting to]]: in-world Voice Chat...
* [2008/07/15 9:28] [[User:Connected undefined|Connected undefined]]:
* [2008/07/15 9:32] [[User:Saijanai Kuhn|Saijanai Kuhn]]: hey all. Split attention right now
* [2008/07/15 9:32] [[User:Dahlia Trimble|Dahlia Trimble]]: Hi :)
* [2008/07/15 9:32] [[User:Bartholomew Kleiber|Bartholomew Kleiber]]: hi all
* [2008/07/15 9:32] [[User:Zha Ewry|Zha Ewry]]: Hello everyone
* [2008/07/15 9:33] [[User:Zha Ewry|Zha Ewry]]: So.. we're going to hopeflly chew on the stuff needed to do trust in the large
* [2008/07/15 9:33] [[User:Goldie Katsu|Goldie Katsu]]: I trust that will work :)
* [2008/07/15 9:33] [[User:Zha Ewry|Zha Ewry]]: And.. fair warning... if you talk about this stuff, you will probably find loud noisy comments posted on your blogs, and your name in other people's blogs
* [2008/07/15 9:34] [[User:Zha Ewry|Zha Ewry]]: I tossed some roadmap thoughts for this space out on my blog.. and it got, ahm.. noisy
* [2008/07/15 9:35] [[User:Tao Takashi|Tao Takashi]]: sorry, need to head over to the pyogp meeting again
* [2008/07/15 9:35] [[User:Zha Ewry|Zha Ewry]]: [http://zhaewry.wordpress.com/2008/07/09/identity-trust-and-policy/]
* [2008/07/15 9:35] [[User:Dahlia Trimble|Dahlia Trimble]]: someone likes you Zha?
* [2008/07/15 9:35] [[User:Saijanai Kuhn|Saijanai Kuhn]]: me has an alt (ad incredible lag)
* [2008/07/15 9:35] [[User:Goldie Katsu|Goldie Katsu]]: People feel strongly about this "grid" we inhabit.
* [2008/07/15 9:35] [[User:Saijanai Kuhn|Saijanai Kuhn]]: Prokofy deconstructed it "line by line" amazing thourght processes insight
* [2008/07/15 9:36] [[User:Zha Ewry|Zha Ewry]]: nods
* [2008/07/15 9:36] [[User:Dahlia Trimble|Dahlia Trimble]]: I saw Prok's blog posting
* [2008/07/15 9:36] [[User:Goldie Katsu|Goldie Katsu]]: Amazing the skills being a translator give you for analysis of things.
* [2008/07/15 9:36] [[User:Zha Ewry|Zha Ewry]]: sighs
* [2008/07/15 9:36] [[User:Dahlia Trimble|Dahlia Trimble]]: skills? :/
* [2008/07/15 9:36] [[User:Zha Ewry|Zha Ewry]]: Amazing what happens when you try to view the world through a "I don't trust anyone's motives" filter
* [2008/07/15 9:36] [[User:Rex Cronon|Rex Cronon]]: hello everybody
* [2008/07/15 9:37] [[User:Dahlia Trimble|Dahlia Trimble]]: HI :)
* [2008/07/15 9:37] [[User:Zha Ewry|Zha Ewry]]: So... In general, I think that roadmap is about right.
* [2008/07/15 9:37] [[User:Zha Ewry|Zha Ewry]]: We anchor in proof that the sims are who they say they are
* [2008/07/15 9:37] [[User:Zha Ewry|Zha Ewry]]: We likewise, need to anchor in proof that the users are who they say they are
* [2008/07/15 9:37] [[User:Zha Ewry|Zha Ewry]]: we provide a policy plug point, for various ways of expressoins policy
* [2008/07/15 9:39] [[User:Zha Ewry|Zha Ewry]]: and.. we do an early example of the xisting behavior
* [2008/07/15 9:41] [[User:Zha Ewry|Zha Ewry]]: In particular, we want to be able to say, I think
* [2008/07/15 9:42] [[User:Zha Ewry|Zha Ewry]]: "here is how the proposed stacks will yield existing behavior between a Linden Style Grid, and a OpenSim Region"
* [2008/07/15 9:43] [[User:Zha Ewry|Zha Ewry]]: eyes the silent crowd
* [2008/07/15 9:43] [[User:Whump Linden|Whump Linden]]: It must be early?
* [2008/07/15 9:43] [[User:Dahlia Trimble|Dahlia Trimble]]: lol
* [2008/07/15 9:43] [[User:Goldie Katsu|Goldie Katsu]]: You just can't see us nodding.
* [2008/07/15 9:44] [[User:Zha Ewry|Zha Ewry]]: laughs
* [2008/07/15 9:44] [[User:Shamir Katsu|Shamir Katsu]]: nods
* [2008/07/15 9:44] [[User:Goldie Katsu|Goldie Katsu]]: When you say "sims are who they say they are"
* [2008/07/15 9:44] [[User:Goldie Katsu|Goldie Katsu]]: do you mean Region Domain and Agent domain pair?
* [2008/07/15 9:44] [[User:Goldie Katsu|Goldie Katsu]]: or where does that part fit?
* [2008/07/15 9:44] [[User:Zha Ewry|Zha Ewry]]: So.. one quick digresoin
* [2008/07/15 9:45] [[User:Zha Ewry|Zha Ewry]]: The long term picture, I think, (and I had a chat with Zero on this last week) is that there is no one to one mapping
* [2008/07/15 9:45] [[User:Zha Ewry|Zha Ewry]]: between regoin domains and agent domains
* [2008/07/15 9:45] [[User:Zha Ewry|Zha Ewry]]: Lots of permutations, just sets of services grouped for our own convenicne as we do various deploys
* [2008/07/15 9:45] [[User:Zha Ewry|Zha Ewry]]: But...
* [2008/07/15 9:45] [[User:Zha Ewry|Zha Ewry]]: that said
* [2008/07/15 9:46] [[User:Zha Ewry|Zha Ewry]]: I think we need good, simple, ways of being able to prove to each other
* [2008/07/15 9:46] [[User:Zha Ewry|Zha Ewry]]: "I am part of the lastdiehardAOLservers.com region domain"
* [2008/07/15 9:47] [[User:Zha Ewry|Zha Ewry]]: And likewise for the round trip
* [2008/07/15 9:47] [[User:Zha Ewry|Zha Ewry]]: so...
* [2008/07/15 9:47] [[User:Goldie Katsu|Goldie Katsu]]: Can I throw in one more question here.
* [2008/07/15 9:47] [[User:Saijanai Kuhn|Saijanai Kuhn]]: someone else will have to handle the transcript. the new RC doesn't like to run two copies
* [2008/07/15 9:47] [[User:Goldie Katsu|Goldie Katsu]]: (OK 2 since I just asked one)
* [2008/07/15 9:47] [[User:Zha Ewry|Zha Ewry]]: "ChartruseIslandsAgentDomain" can prove to "JoesGarage" that it is in fatc who it says it is
* [2008/07/15 9:47] [[User:Zha Ewry|Zha Ewry]]: Go ahead
* [2008/07/15 9:48] [[User:A group|A group]]: member named Mankind Tracer gave you Mankind Tracer in Amsterdam - Sim Notice on Stream.
* [2008/07/15 9:48] [[User:Goldie Katsu|Goldie Katsu]]: Does this mean that there could be a region domain that has no associated agent domain, and it just has a trust relationship with other agent domains to provide assets?
* [2008/07/15 9:48] [[User:Zha Ewry|Zha Ewry]]: yes
* [2008/07/15 9:48] [[User:Zha Ewry|Zha Ewry]]: In fact.. I think, long term..
* [2008/07/15 9:49] [[User:Zha Ewry|Zha Ewry]]: it breaks up even more totally
* [2008/07/15 9:49] [[User:Zha Ewry|Zha Ewry]]: No reason we can't have asset servers which serve up to lots of grids
* [2008/07/15 9:49] [[User:Zha Ewry|Zha Ewry]]: All in trust relationships
* [2008/07/15 9:49] [[User:Zha Ewry|Zha Ewry]]: I'm far from convinced that the current utility services need to live inside an agent or region domain, tho.. i can be had on it
* [2008/07/15 9:50] [[User:Goldie Katsu|Goldie Katsu]]: So it isn't just a "sim is who they say they are" but a region is who it says it is, and an agent domain is who it says it is.
* [2008/07/15 9:50] [[User:Zha Ewry|Zha Ewry]]: I think so, yes
* [2008/07/15 9:50] [[User:Goldie Katsu|Goldie Katsu]]: (and I'll try very hard to not wonder if an agent domain can compartmentalize into multiple trust levels.)
* [2008/07/15 9:50] [[User:Zha Ewry|Zha Ewry]]: Because we need to do sort of the full end to end who can we trust story
* [2008/07/15 9:51] [[User:Goldie Katsu|Goldie Katsu]]: So the user trust is two part.
* [2008/07/15 9:51] [[User:Goldie Katsu|Goldie Katsu]]: First you have user by way of client -> agent domain
* [2008/07/15 9:52] [[User:Zha Ewry|Zha Ewry]]: An regoin domain needs to be just as skeptical of agent domains, I think
* [2008/07/15 9:52] [[User:Zha Ewry|Zha Ewry]]: else. you will have osmeone spoof an agent domain, and say
* [2008/07/15 9:52] [[User:Zha Ewry|Zha Ewry]]: "Hey, region, give my user back his rezzed objects" and suck them up
* [2008/07/15 9:52] [[User:Goldie Katsu|Goldie Katsu]]: and then there is the agent domain trust where everyone else trusts the agent domain to correctly identify the agent
* [2008/07/15 9:52] [[User:Goldie Katsu|Goldie Katsu]]: /nods
* [2008/07/15 9:52] [[User:Zha Ewry|Zha Ewry]]: right
* [2008/07/15 9:53] [[User:Zha Ewry|Zha Ewry]]: becuase we're long term, in a peer-to-peer mess
* [2008/07/15 9:53] [[User:Zha Ewry|Zha Ewry]]: which is why I take Morgaine's point, about short haul trust being ideal here
* [2008/07/15 9:54] [[User:Goldie Katsu|Goldie Katsu]]: and there is also how much a client can be trusted by the agent domain.
* [2008/07/15 9:54] [[User:Zha Ewry|Zha Ewry]]: I think we'll really try to avoid long trust chains in SL
* [2008/07/15 9:54] [[User:Zha Ewry|Zha Ewry]]: Heh
* [2008/07/15 9:54] [[User:Zha Ewry|Zha Ewry]]: Yes, Goldie, that's always interesting
* [2008/07/15 9:55] [[User:Zha Ewry|Zha Ewry]]: Ideally, you'd want to prove your AD isn't spoofing
* [2008/07/15 9:55] [[User:Goldie Katsu|Goldie Katsu]]: an MD5 hash alone doesn't actually prove you have a verified client.
* [2008/07/15 9:55] [[User:Saijanai Kuhn|Saijanai Kuhn]]: which is where the worry about EVER transferring control to another agent domain comes in
* [2008/07/15 9:55] [[User:Rex Cronon|Rex Cronon]]: isn't that what the password is used for?
* [2008/07/15 9:56] [[User:Zha Ewry|Zha Ewry]]: Well
* [2008/07/15 9:56] [[User:Goldie Katsu|Goldie Katsu]]: password identifies the user. But the client itself is going to be handling certain tasks and permissions.
* [2008/07/15 9:56] [[User:Goldie Katsu|Goldie Katsu]]: (or more correctly CAPs
* [2008/07/15 9:56] [[User:Goldie Katsu|Goldie Katsu]]: )
* [2008/07/15 9:56] [[User:Dahlia Trimble|Dahlia Trimble]]: maybe AD and regions could use a VPN to comunicate?
* [2008/07/15 9:56] [[User:Zha Ewry|Zha Ewry]]: And worse..
* [2008/07/15 9:56] [[User:Zha Ewry|Zha Ewry]]: How do I know if the endpoint at 9.2.22.23 is in fact really my agent domain?
* [2008/07/15 9:56] [[User:Goldie Katsu|Goldie Katsu]]: Yep.
* [2008/07/15 9:57] [[User:Rex Cronon|Rex Cronon]]: u contact that endpoint with info provided by user
* [2008/07/15 9:57] [[User:Zha Ewry|Zha Ewry]]: But are you sure someone isn't spoofing?
* [2008/07/15 9:58] [[User:Zha Ewry|Zha Ewry]]: I *hate* internet security insanity
* [2008/07/15 9:58] [[User:Goldie Katsu|Goldie Katsu]]: In esscense we are relying on dns and TLS for the client<->agent domain connection
* [2008/07/15 9:58] [[User:Zha Ewry|Zha Ewry]]: Yes
* [2008/07/15 9:58] [[User:Saijanai Kuhn's|Saijanai Kuhn's]]: ISP hsan't fixsed that DNS bug yet :-(
* [2008/07/15 9:58] [[User:Goldie Katsu|Goldie Katsu]]: (luckily the TLS provides some assurance.)
* [2008/07/15 9:58] [[User:Dahlia Trimble|Dahlia Trimble]]: why not set up a VPN when a trust relationship is begun?
* [2008/07/15 9:59] [[User:Shamir Katsu|Shamir Katsu]]: That's what TLS does
* [2008/07/15 9:59] [[User:Zha Ewry|Zha Ewry]]: right for the really paranoid, we can use a cert on login
* [2008/07/15 9:59] [[User:Zha Ewry|Zha Ewry]]: TLS is essentially a secure pipe for HTTP
* [2008/07/15 9:59] [[User:Dahlia Trimble|Dahlia Trimble]]: googles TLS
* [2008/07/15 10:00] [[User:Shamir Katsu|Shamir Katsu]]: TLS is just the more generic name as it can be used with other protocols, e.g., SIP
* [2008/07/15 10:00] [[User:Goldie Katsu|Goldie Katsu]]: (PKI exchange occurs that sets up symmetric key for communications before passing HTTP messages.)
* [2008/07/15 10:01] [[User:Sea Urchin|Sea Urchin]]: beanbags: Going to next texture.
* [2008/07/15 10:01] [[User:Goldie Katsu|Goldie Katsu]]: I can translate what I said into more englishy if anyone needs.
* [2008/07/15 10:01] [[User:Zha Ewry|Zha Ewry]]: So, with TLS, and caps and certs, I think we have a pretty nice set of building blocks
* [2008/07/15 10:01] [[User:Zha Ewry|Zha Ewry]]: I don't think we have a complete story tho
* [2008/07/15 10:02] [[User:Latha Serevi|Latha Serevi]]: (I'm behind today) it's hopeless to seek a "verified client" isn't it? don't we have to expect that the (authenticated, un-spoofed) user will run whatever code they want?
* [2008/07/15 10:02] [[User:Zha Ewry|Zha Ewry]]: We do
* [2008/07/15 10:02] [[User:Goldie Katsu|Goldie Katsu]]: No, because the TLS lets me know it's Joe's Diner but it doesn't tell me what I can do with Joe's Diner or trust Joe's diner to do.
* [2008/07/15 10:02] [[User:Zha Ewry|Zha Ewry]]: We have to assume the client is totally malicious
* [2008/07/15 10:02] [[User:Zha Ewry|Zha Ewry]]: Always the case on the web, really
* [2008/07/15 10:02] [[User:Dahlia Trimble|Dahlia Trimble]]: or some portion of clients are malicious
* [2008/07/15 10:02] [[User:Goldie Katsu|Goldie Katsu]]: If the user has it on their machine we can't trust its veracity
* [2008/07/15 10:03] [[User:Goldie Katsu|Goldie Katsu]]: or trustworthyness
* [2008/07/15 10:03] [[User:Shamir Katsu|Shamir Katsu]]: well from the perspective of the Agent Domain you assume that it is untrusted until proven otherwise, no?
* [2008/07/15 10:03] [[User:Goldie Katsu|Goldie Katsu]]: You can't prove something outside of controlled domain is trustable, you can only limit what you trust it to do.
* [2008/07/15 10:04] [[User:Rex Cronon|Rex Cronon]]: with the code for the viewer being opensource, i don't think u can ever assume that the viewer can be trusted
* [2008/07/15 10:04] [[User:Saijanai Kuhn|Saijanai Kuhn]]: given the existence of several viewers anyway...
* [2008/07/15 10:04] [[User:Zha Ewry|Zha Ewry]]: You can't anyway, Rex, since. someone can just right C++ to the pipe and be untrusted
* [2008/07/15 10:04] [[User:Zha Ewry|Zha Ewry]]: *write
* [2008/07/15 10:04] [[User:Goldie Katsu|Goldie Katsu]]: yep
* [2008/07/15 10:04] [[User:Saijanai Kuhn|Saijanai Kuhn]]: SLProxy...
* [2008/07/15 10:04] [[User:Dahlia Trimble|Dahlia Trimble]]: I dont think limiting connections to SL type viewers is Opensim's goal anyway
* [2008/07/15 10:04] [[User:Zha Ewry|Zha Ewry]]: We can.. withing reason have good trust betwee sims and ADs and sims and sims
* [2008/07/15 10:05] [[User:Zha Ewry|Zha Ewry]]: Hardly, Dahlia
* [2008/07/15 10:05] [[User:Goldie Katsu|Goldie Katsu]]: yeah even sending a signature could have a MIM (man in the middle) attack.
* [2008/07/15 10:05] [[User:Zha Ewry|Zha Ewry]]: and the OGP goal is tobe broad enough to not even assume the "client" is a viewer
* [2008/07/15 10:05] [[User:Goldie Katsu|Goldie Katsu]]: :)
* [2008/07/15 10:05] [[User:Zha Ewry|Zha Ewry]]: when you think of the client, as just a set of service/caps which happen to result in rndering of the world
* [2008/07/15 10:05] [[User:Saijanai Kuhn|Saijanai Kuhn]]: Maya-OpenSim plugin for builders
* [2008/07/15 10:06] [[User:Zha Ewry|Zha Ewry]]: then.. we have to asume, it might, for example, be a videa stream generating client. No user at all, just a view bot, and a quicktime stream out the backend
* [2008/07/15 10:06] [[User:Latha Serevi|Latha Serevi]]: The client is maybe a "set of interests" having to do with gathering the relevant info to a particular avatar in the world.
* [2008/07/15 10:07] [[User:A group|A group]]: member named Kira Ahn gave you New Releases 150708 (please unpack).
* [2008/07/15 10:07] [[User:Zha Ewry|Zha Ewry]]: I think, that, at the moment, it's about that, youcould imaine re-factroring even further
* [2008/07/15 10:07] [[User:Goldie Katsu|Goldie Katsu]]: Actually it breaks down even further
* [2008/07/15 10:07] [[User:Zha Ewry|Zha Ewry]]: just for fun.. contemplate.. a client wh's only purpose is to grab the chat here, for a web page view o fit, and an archive
* [2008/07/15 10:08] [[User:Saijanai Kuhn|Saijanai Kuhn]]: camera bots already exist and there's that nice meta-microphone thing that metanomics uses
* [2008/07/15 10:08] [[User:Zha Ewry|Zha Ewry]]: Yes
* [2008/07/15 10:08] [[User:Latha Serevi|Latha Serevi]]: I was describing the common case of "avatar-representing client" I guess.
* [2008/07/15 10:08] [[User:Zha Ewry|Zha Ewry]]: So... imagine those as first class clients (or more specfically)
* [2008/07/15 10:09] [[User:Saijanai Kuhn|Saijanai Kuhn]]: I think he showed up a few minutes after everyone else left
* [2008/07/15 10:09] [[User:Goldie Katsu|Goldie Katsu]]: However, I think in the current model the client authenticates to the agent domain to a particular agent which maps to one or more avatars (is that right) and then a particular avatar identity would be connected to a region (whether it would rez or just grab a stream is an implementation detail.)
* [2008/07/15 10:09] [[User:Zha Ewry|Zha Ewry]]: So, yes
* [2008/07/15 10:09] [[User:Zha Ewry|Zha Ewry]]: I agree Latha, that's the most common use case
* [2008/07/15 10:10] [[User:Zha Ewry|Zha Ewry]]: just. .as we peel the onion here, a bit, we want to cover the full range
* [2008/07/15 10:11] [[User:Goldie Katsu|Goldie Katsu]]: Oops correction: , I think in the current model the client authenticates to the agent domain to a particular account which maps to one or more agents (is that right) and then a particular agent identity would be connected to a region (whether it would rez or just grab a stream is an implementation detail.)
* [2008/07/15 10:12] [[User:Goldie Katsu|Goldie Katsu]]: so the agent would connect to a region in any case, whether it just gathers text, video or sends data.
* [2008/07/15 10:13] [[User:ZHAO Ninja|ZHAO Ninja]]: AO set: Could not find animation 'ninjya-run'
* [2008/07/15 10:13] [[User:Zha Ewry|Zha Ewry]]: I am increasinly, seeingf this as a set of sewrvices, which factor into the domains
* [2008/07/15 10:13] [[User:ZHAO Ninja|ZHAO Ninja]]: AO set: Could not find animation 'ninjya-run'.
* [2008/07/15 10:13] [[User:Zha Ewry|Zha Ewry]]: and. that we build trust around those domains, so we dont end up with soup
* [2008/07/15 10:14] [[User:Goldie Katsu|Goldie Katsu]]: So there is identity trust and there is some other kind of trust involved.
* [2008/07/15 10:14] [[User:Saijanai Kuhn|Saijanai Kuhn]]: one thing to point out is that connecting to a domain would be a multi-part process. You might have domain-specific inventory and groups for xample
* [2008/07/15 10:15] [[User:Saijanai Kuhn|Saijanai Kuhn]]: which could appy before rez_avtar
* [2008/07/15 10:15] [[User:Latha Serevi|Latha Serevi]]: Identity trust at the base, and then each separate unit can associate capabilities with that identity. That's enough to bootstrap. But, a layer above that seems important for practical interoperability.
* [2008/07/15 10:16] [[User:Latha Serevi|Latha Serevi]]: By the way, regarding un-spoofable communications, it's straightforward for you and me to set up a secure communication channel over insecure links, if we know we have each other's public keys. We're clear on that, right?
* [2008/07/15 10:16] [[User:Zha Ewry|Zha Ewry]]: yes, if we have keys in place
* [2008/07/15 10:16] [[User:Zha Ewry|Zha Ewry]]: Unspoofable, but not trustable, that the endpoint is well behaved
* [2008/07/15 10:17] [[User:Goldie Katsu|Goldie Katsu]]: The problem with VPNs is their endpoints :)
* [2008/07/15 10:17] [[User:Zha Ewry|Zha Ewry]]: ie, once I send you the key, you can use it in a malcisous bit of software
* [2008/07/15 10:17] [[User:Zha Ewry|Zha Ewry]]: sighs
* [2008/07/15 10:17] [[User:Latha Serevi|Latha Serevi]]: It's nice that spoofing seems to be a completely squashable problem. One less thing.
* [2008/07/15 10:17] [[User:Sea Urchin|Sea Urchin]]: beanbags: llStopAnimation: Script trying to stop animations but agent not found
* [2008/07/15 10:17] [[User:Zha Ewry|Zha Ewry]]: right
* [2008/07/15 10:17] [[User:Zha Ewry|Zha Ewry]]: So. another personal perference
* [2008/07/15 10:18] [[User:Zha Ewry|Zha Ewry]]: and you see it in TLS being prominent
* [2008/07/15 10:18] [[User:Zha Ewry|Zha Ewry]]: is to do this with as many base web bits as possible
* [2008/07/15 10:18] [[User:Zha Ewry|Zha Ewry]]: 90% of this, is about collections of web services working together
* [2008/07/15 10:18] [[User:Zha Ewry|Zha Ewry]]: so.. if we can stay deep in the middle of the web service space, I think we get a lot of benefits
* [2008/07/15 10:19] [[User:Goldie Katsu|Goldie Katsu]]: So what (types of) domains do we have that will each be authenticating to each other.
* [2008/07/15 10:20] [[User:Goldie Katsu|Goldie Katsu]]: I'm seeing Agent Domain, Region Domain and to a limited extent Client.
* [2008/07/15 10:20] [[User:Goldie Katsu|Goldie Katsu]]: are there more?
* [2008/07/15 10:20] [[User:Zha Ewry|Zha Ewry]]: I think one more
* [2008/07/15 10:20] [[User:Zha Ewry|Zha Ewry]]: which is utitlities
* [2008/07/15 10:20] [[User:Goldie Katsu|Goldie Katsu]]: and what is in Utilities?
* [2008/07/15 10:20] [[User:Zha Ewry|Zha Ewry]]: Where things like the lindex, and asset servers might live
* [2008/07/15 10:20] [[User:Zha Ewry|Zha Ewry]]: The factoring of the world I see developing
* [2008/07/15 10:20] [[User:Goldie Katsu|Goldie Katsu]]: and there might be multiple Utilities domains?
* [2008/07/15 10:20] [[User:Zha Ewry|Zha Ewry]]: is...
* [2008/07/15 10:21] [[User:Zha Ewry|Zha Ewry]]: Oh, defintiely
* [2008/07/15 10:21] [[User:Zha Ewry|Zha Ewry]]: "Stuff about spaces" (regoin domain)
* [2008/07/15 10:21] [[User:Zha Ewry|Zha Ewry]]: "Stuff about agents (ie) users) " (Agent domain)
* [2008/07/15 10:21] [[User:Zha Ewry|Zha Ewry]]: And.. utiltiites regions use (Lindex, Searxh, etc)
* [2008/07/15 10:21] [[User:Whump Linden|Whump Linden]]: Zha, could you elaborate why asset servers might not be part of the Agent Domain?
* [2008/07/15 10:22] [[User:Zha Ewry|Zha Ewry]]: I am reluctant to hae the third be just a random blob yet
* [2008/07/15 10:22] [[User:Sea Urchin|Sea Urchin]]: beanbags: Going to next texture.
* [2008/07/15 10:22] [[User:Zha Ewry|Zha Ewry]]: Because, I think there are lots of assets which aren't owned by users
* [2008/07/15 10:22] [[User:Zha Ewry|Zha Ewry]]: Things like libraries of content
* [2008/07/15 10:22] [[User:Zha Ewry|Zha Ewry]]: And.. it is also really, nice to break the tie between
* [2008/07/15 10:22] [[User:Zha Ewry|Zha Ewry]]: "This domain hosts my account"
* [2008/07/15 10:23] [[User:Zha Ewry|Zha Ewry]]: and "this domain holds *all* my stuff"
* [2008/07/15 10:23] [[User:Goldie Katsu|Goldie Katsu]]: And...where do groups fit? Or should current uses of groups be split into two (or more) other things. IM and notices are quite different from land perms and it is a complex mixture to combine them.
* [2008/07/15 10:23] [[User:Zha Ewry|Zha Ewry]]: Well
* [2008/07/15 10:23] [[User:Zha Ewry|Zha Ewry]]: I'd love to see that factoring, at least
* [2008/07/15 10:23] [[User:Zha Ewry|Zha Ewry]]: We talked about this a bit
* [2008/07/15 10:23] [[User:Zha Ewry|Zha Ewry]]: in openSim-dev
* [2008/07/15 10:24] [[User:Zha Ewry|Zha Ewry]]: and it really seems to me, that group IM is much easier to grid span than
* [2008/07/15 10:24] [[User:Zha Ewry|Zha Ewry]]: land ownership rights for example
* [2008/07/15 10:24] [[User:Zha Ewry|Zha Ewry]]: As serviices?
* [2008/07/15 10:24] [[User:Goldie Katsu|Goldie Katsu]]: It also means that you can be in group IMs without being in a virtual world potentially.
* [2008/07/15 10:24] [[User:Zha Ewry|Zha Ewry]]: I'm not so worrried about it in the short term
* [2008/07/15 10:24] [[User:Zha Ewry|Zha Ewry]]: Yep
* [2008/07/15 10:25] [[User:Zha Ewry|Zha Ewry]]: As we scale out, things like that feel really important too
* [2008/07/15 10:25] [[User:Sea Urchin|Sea Urchin]]: beanbags: Going to next texture.
* [2008/07/15 10:25] [[User:Latha Serevi|Latha Serevi]]: The basic build of a region seems to belong to the region. Sure, it can be forced to have an owner, but it's an uneasy fit. So, what kind of entity can own an object?
* [2008/07/15 10:25] [[User:Zha Ewry|Zha Ewry]]: Interesting question Latha
* [2008/07/15 10:26] [[User:Zha Ewry|Zha Ewry]]: anyone who's done a bunch of group building knows its a mess in SL
* [2008/07/15 10:26] [[User:Zha Ewry|Zha Ewry]]: harkening back to my MUD/MOO/MUSH days
* [2008/07/15 10:26] [[User:Latha Serevi|Latha Serevi]]: (or does "own" decompose into "hold the keys to", "stores the bits of", and "has permission to modify"...
* [2008/07/15 10:26] [[User:Goldie Katsu|Goldie Katsu]]: yes. And for corporations who want to own the output of work it is a special challenge.
* [2008/07/15 10:26] [[User:Zha Ewry|Zha Ewry]]: we had some really cool content library stuff
* [2008/07/15 10:27] [[User:Zha Ewry|Zha Ewry]]: so.. I think Latha, that was exactly th right question
* [2008/07/15 10:27] [[User:Zha Ewry|Zha Ewry]]: Who has the keys
* [2008/07/15 10:27] [[User:Zha Ewry|Zha Ewry]]: who can control it
* [2008/07/15 10:27] [[User:Zha Ewry|Zha Ewry]]: in the current model of the world
* [2008/07/15 10:27] [[User:Zha Ewry|Zha Ewry]]: Regions, hold stuff
* [2008/07/15 10:27] [[User:Rodriguez Hird|Rodriguez Hird]]: afk
* [2008/07/15 10:28] [[User:Latha Serevi|Latha Serevi]]: Some one (or small number) of entities will have the keys; but they'll also have a map of who they'll allow to twiddle the object by proxy. That map interests me too.
* [2008/07/15 10:28] [[User:Zha Ewry|Zha Ewry]]: In really odd ways
* [2008/07/15 10:29] [[User:Zha Ewry|Zha Ewry]]: nods
* [2008/07/15 10:29] [[User:Zha Ewry|Zha Ewry]]: So. right now, if you rez a block on this sim
* [2008/07/15 10:29] [[User:Zha Ewry|Zha Ewry]]: The sim holds it as a paersistent object
* [2008/07/15 10:29] [[User:Zha Ewry|Zha Ewry]]: Not in your inventory
* [2008/07/15 10:29] [[User:Zha Ewry|Zha Ewry]]: just in the sim
* [2008/07/15 10:29] [[User:Zha Ewry|Zha Ewry]]: That's really odd in many ways
* [2008/07/15 10:30] [[User:Latha Serevi|Latha Serevi]]: Regions holding stuff in odd ways - my instinct is that the LL model will have to be modified quite a bit in order to fit an open-sim model at all. Compatible, maybe, but very different underlying set of assumptions. Like zha said.
* [2008/07/15 10:30] [[User:Zha Ewry|Zha Ewry]]: You can only find it, and manipulate it, if you com ehere in person
* [2008/07/15 10:30] [[User:Zha Ewry|Zha Ewry]]: well, 90% of the OpenSim code follows Lindne's lead
* [2008/07/15 10:31] [[User:Latha Serevi|Latha Serevi]]: ""Where objects exist" is in the 10% though!
* [2008/07/15 10:31] [[User:Latha Serevi|Latha Serevi]]: or had better be
* [2008/07/15 10:31] [[User:Zha Ewry|Zha Ewry]]: somewhat
* [2008/07/15 10:31] [[User:Zha Ewry|Zha Ewry]]: Less than you might expect
* [2008/07/15 10:31] [[User:Zha Ewry|Zha Ewry]]: You can lose prims on OpenSim in disturbingly simialr ways
* [2008/07/15 10:33] [[User:Goldie Katsu|Goldie Katsu]]: I like separating out the asset, but it does pose an interesting point on trust.
* [2008/07/15 10:34] [[User:Latha Serevi|Latha Serevi]]: For the basic case of a no-copy object rezzed in a region ... the LL assumption is that it has been erased from the agent domain. And presumably you'll want to support that policy approach. But don't we also need a set of permission bits to pass around to allow implementing the "AD keeps a copy of course, even for no-copy objects rezzed somewhere, with permission bits set appropriately"
* [2008/07/15 10:34] [[User:Zha Ewry|Zha Ewry]]: I agree
* [2008/07/15 10:34] [[User:Zha Ewry|Zha Ewry]]: One of the major goals of the OGP work
* [2008/07/15 10:34] [[User:Zha Ewry|Zha Ewry]]: shoudl eb to enable a much broader set of choices
* [2008/07/15 10:36] [[User:Goldie Katsu|Goldie Katsu]]: So we have 3 domains (plus a client)
* [2008/07/15 10:36] [[User:Goldie Katsu|Goldie Katsu]]: Is the identity trust simply based on TLS?
* [2008/07/15 10:38] [[User:Zha Ewry|Zha Ewry]]: Good questoiun
* [2008/07/15 10:38] [[User:Latha Serevi|Latha Serevi]]: In my mind, we have a large number of identities with different capabilities granted to them. A common case is, 3 domains (agent, region, utility) plus a client. (maybe 4, adding L$ ?) . Correct me if this sounds broken.
* [2008/07/15 10:39] [[User:Goldie Katsu|Goldie Katsu]]: I would think separating the L$ makes sense.
* [2008/07/15 10:39] [[User:Zha Ewry|Zha Ewry]]: I think the nice thing, ias when its a set?
* [2008/07/15 10:39] [[User:Zha Ewry|Zha Ewry]]: Once it's more than 2+ client
* [2008/07/15 10:39] [[User:Zha Ewry|Zha Ewry]]: you're in the general case
* [2008/07/15 10:39] [[User:Goldie Katsu|Goldie Katsu]]: I hvae a bank that is separate from my utliities
* [2008/07/15 10:39] [[User:Zha Ewry|Zha Ewry]]: If we decide to add domains beyond 2.. you're prety much in the general case for problem solving
* [2008/07/15 10:39] [[User:Goldie Katsu|Goldie Katsu]]: I may trust Xcel for my power and gas, but I wouldn't trust them with my pacheck.
* [2008/07/15 10:39] [[User:Goldie Katsu|Goldie Katsu]]: True
* [2008/07/15 10:40] [[User:Zha Ewry|Zha Ewry]]: As a prtocol/design goal
* [2008/07/15 10:40] [[User:Zha Ewry|Zha Ewry]]: we should also make it pretty easy, to mark untrusted stuff, as well
* [2008/07/15 10:41] [[User:Saijanai Kuhn|Saijanai Kuhn]]: This is where Which's expertise comes in, I think
* [2008/07/15 10:41] [[User:Zha Ewry|Zha Ewry]]: "I'm a wild west region"
* [2008/07/15 10:41] [[User:Zha Ewry|Zha Ewry]]: They'll exist, we ought to plan for them
* [2008/07/15 10:41] [[User:Goldie Katsu|Goldie Katsu]]: Yes.
* [2008/07/15 10:42] [[User:Goldie Katsu|Goldie Katsu]]: Which means in the asset service there needs to be a way to have untrusted assets and assets that cannot be rezzed in untrusted regions. trust here being "I trust this region to handle assets correctly"
* [2008/07/15 10:42] [[User:Goldie Katsu|Goldie Katsu]]: or soemthing like that.
* [2008/07/15 10:42] [[User:Zha Ewry|Zha Ewry]]: Yeah
* [2008/07/15 10:42] [[User:Zha Ewry|Zha Ewry]]: I think we want to have that flexability
* [2008/07/15 10:43] [[User:Zha Ewry|Zha Ewry]]: What's just a bad idea is to pretend we won't have the full range
* [2008/07/15 10:43] [[User:Goldie Katsu|Goldie Katsu]]: yes. Don't assume a safe interent :)
* [2008/07/15 10:44] [[User:Latha Serevi|Latha Serevi]]: "trusted region", bad term. All regions should have an identity, or we won't even talk to them. (Identities had better be available to anybody easily). "untrusted" is more like "doesn't promise to my satisfaction to preserve my permissions"
* [2008/07/15 10:44] [[User:Shamir Katsu|Shamir Katsu]]: There just needs to be a way to encapsulate and share that notion of trust and it has to be granular enough to support those assertions on individual objects for each context
* [2008/07/15 10:45] [[User:Goldie Katsu|Goldie Katsu]]: So identity trust is pretty simple I trust you are Zha true/false. (which implies a transitive trust that I trust the region to show me the right agent name, and the region trusted that the agent domain passed the right agent information and the agent domain trusted that the client to authenticate.)
* [2008/07/15 10:45] [[User:Zha Ewry|Zha Ewry]]: Well, if we do this at all right, we're building a bunch of stuff which scales out and grows into somethingvery much like the web
* [2008/07/15 10:45] [[User:Zha Ewry|Zha Ewry]]: Truted regoin is a very bad term
* [2008/07/15 10:45] [[User:Zha Ewry|Zha Ewry]]: as you say its
* [2008/07/15 10:45] [[User:Zha Ewry|Zha Ewry]]: "Compatible with doing X"
* [2008/07/15 10:46] [[User:Latha Serevi|Latha Serevi]]: goldie, no on the transitive trust I think. Go check the public key index and handshake with the identity you want to communicate with.
* [2008/07/15 10:46] [[User:Zha Ewry|Zha Ewry]]: As little chained trust as possible feels right to me
* [2008/07/15 10:47] [[User:Latha Serevi|Latha Serevi]]: denial of service possible, but not spoofing, if the link is malicious
* [2008/07/15 10:47] [[User:Object: llStopAnimation|Object: llStopAnimation]]: Script trying to stop animations but agent not found
* [2008/07/15 10:47] [[User:Goldie Katsu|Goldie Katsu]]: Ok, let me reframe what I meant (without me getting lost in details that fit futher down )
* [2008/07/15 10:47] [[User:Goldie Katsu|Goldie Katsu]]: Identity trust is easy A is or is not believed to be A
* [2008/07/15 10:47] [[User:Shamir Katsu|Shamir Katsu]]: The reason you need trust to be sharable is otherwise everyone ends up having to do their own authentication
* [2008/07/15 10:48] [[User:Goldie Katsu|Goldie Katsu]]: the hard part comes in defining what capabilities we trust A to do on your behalf.
* [2008/07/15 10:48] [[User:Zha Ewry|Zha Ewry]]: Right, Shamir.. if we don't do it pretty broadly.. we don't get it in a useful way
* [2008/07/15 10:48] [[User:Dahlia Trimble|Dahlia Trimble]]: gotta go, bye all :)
* [2008/07/15 10:48] [[User:Latha Serevi|Latha Serevi]]: shamir, I think they should do their own. OK, you can have a proxy for that if you must, but in our minds everybody can take the time to authenticate everybody else.
* [2008/07/15 10:48] [[User:Goldie Katsu|Goldie Katsu]]: (And there has to be transitive trust/chained trust of some sort because I can only see that the region shows my client that the agent Zha is in this sim.)
* [2008/07/15 10:49] [[User:Zha Ewry|Zha Ewry]]: Sure, but as little as possible
* [2008/07/15 10:49] [[User:Rex Cronon|Rex Cronon]]: bye dahlia
* [2008/07/15 10:49] [[User:Zha Ewry|Zha Ewry]]: bye Dahlia
* [2008/07/15 10:49] [[User:Goldie Katsu|Goldie Katsu]]: bye Dahlia
* [2008/07/15 10:49] [[User:Goldie Katsu|Goldie Katsu]]: and the region only knows Zha is here because the agent Domain said it was the agent Zha
* [2008/07/15 10:49] [[User:Latha Serevi|Latha Serevi]]: goldie, agree on binary identity trust. disagree on the rest; if it's important, go check.
* [2008/07/15 10:50] [[User:Latha Serevi|Latha Serevi]]: (so maybe there are multiple states - "unverified agent Zha seems to be here"
* [2008/07/15 10:50] [[User:Zha Ewry|Zha Ewry]]: Yeah, that last is nasty, Latha
* [2008/07/15 10:50] [[User:Goldie Katsu|Goldie Katsu]]: Yes that fits in the next level.
* [2008/07/15 10:50] [[User:Goldie Katsu|Goldie Katsu]]: Region domain's can't verify an agent identity except through the agent domain.
* [2008/07/15 10:51] [[User:Latha Serevi|Latha Serevi]]: Why nasty? Avatar abcd just hasn't been verifiably linked to identity Zha by me yet.
* [2008/07/15 10:51] [[User:Goldie Katsu|Goldie Katsu]]: But the region domain agent domain trust can define "Identies are verified" "Identities are questionable" "identities are unverified"
* [2008/07/15 10:52] [[User:Latha Serevi|Latha Serevi]]: Hmm, I wonder if we're talking two different situations here. In principle, there's no need to delegate to AD and RD except to establish comms. But, in a common case....
* [2008/07/15 10:53] [[User:Latha Serevi|Latha Serevi]]: ...common case, agents in AD have delegated AD as trusted to authenticate them?
* [2008/07/15 10:53] [[User:Zha Ewry|Zha Ewry]]: You'd rather never have me here, unverified, at some level
* [2008/07/15 10:54] [[User:Goldie Katsu|Goldie Katsu]]: Here, but perhaps in wild west?
* [2008/07/15 10:54] [[User:Goldie Katsu|Goldie Katsu]]: Like the black and whites in Snow Crash?
* [2008/07/15 10:54] [[User:Zha Ewry|Zha Ewry]]: True
* [2008/07/15 10:54] [[User:Zha Ewry|Zha Ewry]]: So. OK, yes, we'll see those
* [2008/07/15 10:55] [[User:Goldie Katsu|Goldie Katsu]]: So do we need to identify expected/likely trust chains?
* [2008/07/15 10:56] [[User:Zha Ewry|Zha Ewry]]: That would be a nice exercise, I think
* [2008/07/15 10:56] [[User:Goldie Katsu|Goldie Katsu]]: So what do we call this other trust that isn't identity trust.
* [2008/07/15 10:57] [[User:Goldie Katsu|Goldie Katsu]]: And when I say identity trust here I mean that domain A or client B are domain A or client B
* [2008/07/15 10:57] [[User:Goldie Katsu|Goldie Katsu]]: not that the agent itself is who it says it is.
* [2008/07/15 10:58] [[User:[ Organica|[ Organica]]:
* [2008/07/15 10:58] [[User:Goldie Katsu|Goldie Katsu]]: Layer 1 identity in the <pick a name here> model.
* [2008/07/15 10:59] [[User:Latha Serevi|Latha Serevi]]: layer 2, map from identity to capabilities? (maintained by each identity separately for each other at this layer)
* [2008/07/15 11:00] [[User:Zha Ewry|Zha Ewry]]: listens carefully
* [2008/07/15 11:00] [[User:Latha Serevi|Latha Serevi]]: uh oh :)
* [2008/07/15 11:00] [[User:Goldie Katsu|Goldie Katsu]]: Layer 2 gets very tricky.
* [2008/07/15 11:00] [[User:Zha Ewry|Zha Ewry]]: Very
* [2008/07/15 11:01] [[User:Goldie Katsu|Goldie Katsu]]: I think layer 2 is internal to a domain?
* [2008/07/15 11:01] [[User:Goldie Katsu|Goldie Katsu]]: and layer 3 would be interdomain
* [2008/07/15 11:01] [[User:Zha Ewry|Zha Ewry]]: That would be nice
* [2008/07/15 11:01] [[User:Zha Ewry|Zha Ewry]]: If it's moslty internal, we can keep it contained
* [2008/07/15 11:02] [[User:Saijanai Kuhn|Saijanai Kuhn]]: this starts to feel like something that requires a very sophisticated mathematical analysis to make sure you've covered properly all the cases you've exposed
* [2008/07/15 11:02] [[User:Latha Serevi|Latha Serevi]]: What's a domain? I think of them as just meta-identities, so my base would be the domain of size 1.
* [2008/07/15 11:02] [[User:Goldie Katsu|Goldie Katsu]]: Domain would be an Agent Doman or a region domain (or utilities domain?) as defined in OGP?
* [2008/07/15 11:03] [[User:Zha Ewry|Zha Ewry]]: I htink of a domain as a collection of services with common properties and a way of proving membership
* [2008/07/15 11:03] [[User:Goldie Katsu|Goldie Katsu]]: Much better definition.
* [2008/07/15 11:03] [[User:Goldie Katsu|Goldie Katsu]]: Just looking at an agent domain - 2 users may be trusted with different capabilities.
* [2008/07/15 11:03] [[User:Zha Ewry|Zha Ewry]]: has been trying really hard to get that one right
* [2008/07/15 11:04] [[User:Latha Serevi|Latha Serevi]]: So far, we can only prove individual identity. maybe (next meeting?) talk about how to prove membership in a group?
* [2008/07/15 11:04] [[User:Rex Cronon|Rex Cronon]]: i have to go, bye everybody
* [2008/07/15 11:04] [[User:Goldie Katsu|Goldie Katsu]]: Bye Rex
* [2008/07/15 11:04] [[User:Rex Cronon|Rex Cronon]]: tc
* [2008/07/15 11:04] [[User:Zha Ewry|Zha Ewry]]: Sounds like a pan Latha
* [2008/07/15 11:05] [[User:Zha Ewry|Zha Ewry]]: *plan
* [2008/07/15 11:05] [[User:Latha Serevi|Latha Serevi]]: Group/domain membership infrastructure seems do-able and important.
* [2008/07/15 11:05] [[User:Goldie Katsu|Goldie Katsu]]: yep.
* [2008/07/15 11:05] [[User:Zha Ewry|Zha Ewry]]: I generally take 11:00 SL as time to start windingf down
* [2008/07/15 11:05] [[User:Zha Ewry|Zha Ewry]]: and. very much so, Latha
* [2008/07/15 11:05] [[User:Zha Ewry|Zha Ewry]]: if we nail that.. the rest has a place to anchor
* [2008/07/15 11:05] [[User:Goldie Katsu|Goldie Katsu]]: and looking at the trust chains
* [2008/07/15 11:05] [[User:Goldie Katsu|Goldie Katsu]]: which would be after the previous if there's time
* [2008/07/15 11:05] [[User:Latha Serevi|Latha Serevi]]: The business about capability maps and distributing them needs more work & bootstrapping.
* [2008/07/15 11:06] [[User:Latha Serevi|Latha Serevi]]: (= trust chains)
* [2008/07/15 11:06] [[User:Goldie Katsu|Goldie Katsu]]: Trust needs to be built up by layers.
* [2008/07/15 11:06] [[User:Zha Ewry|Zha Ewry]]: Short trust chains
* [2008/07/15 11:06] [[User:Zha Ewry|Zha Ewry]]: Layers and short chians
* [2008/07/15 11:06] [[User:Goldie Katsu|Goldie Katsu]]: Yep.
* [2008/07/15 11:06] [[User:Zha Ewry|Zha Ewry]]: OK
* [2008/07/15 11:06] [[User:Goldie Katsu|Goldie Katsu]]: finds hereself thinking of SF
* [2008/07/15 11:06] [[User:Zha Ewry|Zha Ewry]]: Saij?
* [2008/07/15 11:06] [[User:Zha Ewry|Zha Ewry]]: If I pass you a e-mail with the chat log, can you format and post it?
* [2008/07/15 11:08] [[User:Zha Ewry|Zha Ewry]]: mutters
* [2008/07/15 11:08] [[User:Zha Ewry|Zha Ewry]]: OK
* [2008/07/15 11:08] [[User:Zha Ewry|Zha Ewry]]: Well, I have it I guess time to format
* [2008/07/15 11:08] [[User:Latha Serevi|Latha Serevi]]: (don't forget to translate "You:" into "Zha Ewry:")
* [2008/07/15 11:08] [[User:Zha Ewry|Zha Ewry]]: This was really good, people.
* [2008/07/15 11:09] [[User:Zha Ewry|Zha Ewry]]: yeah, I know
* [2008/07/15 11:09] [[User:Saijanai Kuhn|Saijanai Kuhn]]: sorry was afk again
* [2008/07/15 11:09] [[User:Zha Ewry|Zha Ewry]]: and take out all the declines of the fashcon offers
* [2008/07/15 11:09] [[User:Goldie Katsu|Goldie Katsu]]: :)
* [2008/07/15 11:09] [[User:Saijanai Kuhn|Saijanai Kuhn]]: I just use tree's wikifier page anyway
* [2008/07/15 11:09] [[User:Goldie Katsu|Goldie Katsu]]: Ahh the transcript editing process.
* [2008/07/15 11:09] [[User:Zha Ewry|Zha Ewry]]: You got lnk for that handy?
* [2008/07/15 11:10] [[User:Saijanai Kuhn|Saijanai Kuhn]]: [http://www.treekyomoon.com/wikifier.htm] make sure you enter your name in the settings
* [2008/07/15 11:10] [[User:Zha Ewry|Zha Ewry]]: okies
* [2008/07/15 11:10] [[User:Zha Ewry|Zha Ewry]]: Off to RL for a bit
* [2008/07/15 11:10] [[User:Zha Ewry|Zha Ewry]]: This was SUPER
* [2008/07/15 11:10] [[User:Saijanai Kuhn|Saijanai Kuhn]]: its not reentrant. Last person's settings are the default
* [2008/07/15 11:10] [[User:Goldie Katsu|Goldie Katsu]]: Have fun!
* [2008/07/15 11:10] [[User:Zha Ewry|Zha Ewry]]: Goldie, Latha?
* [2008/07/15 11:11] [[User:Latha Serevi|Latha Serevi]]: mm?
* [2008/07/15 11:11] [[User:Zha Ewry|Zha Ewry]]: Really great to hear all the thinking
* [2008/07/15 11:11] [[User:Goldie Katsu|Goldie Katsu]]: I agree.
* [2008/07/15 11:11] [[User:Goldie Katsu|Goldie Katsu]]: Latha & Zha good stuff.
* [2008/07/15 11:11] [[User:Zha Ewry|Zha Ewry]]: And the quiet input from Shamir too
* [2008/07/15 11:11] [[User:Bartholomew Kleiber|Bartholomew Kleiber]]: bye all
* [2008/07/15 11:11] [[User:Goldie Katsu|Goldie Katsu]]: :)
* [2008/07/15 11:11] [[User:BlueWall Slade|BlueWall Slade]]: thanks! good meeting, great ideas
* [2008/07/15 11:11] [[User:Latha Serevi|Latha Serevi]]: thanks all, til next time
* [2008/07/15 11:11] [[User:Zha Ewry|Zha Ewry]]: Bye all
* [2008/07/15 11:11] [[User:Goldie Katsu|Goldie Katsu]]: Bye all!
* [2008/07/15 11:11] [[User:BlueWall Slade|BlueWall Slade]]: laters
* [2008/07/15 11:11] [[User:Saijanai Kuhn|Saijanai Kuhn]]: laters all
* [2008/07/15 11:11] [[User:Zha Ewry|Zha Ewry]]: See many of you at Zero's
* [2008/07/15 11:11] [[User:Shamir Katsu|Shamir Katsu]]: see ya
*
*

AW Groupies

2008-07-15T19:02:31Z

Zha Ewry: /* Chat Logs */

=Purpose=
Serious technical discussion about Linden Lab's [[Architecture Working Group|Architecture Working Group (AWG)]]. "AW Groupies" is an unofficial, Resident-operated group, though most (all?) members also participate in the AWG.

Invite only (apply in-world to [[User:Zha Ewry|Zha Ewry]]), but the criterion is simple. Show up and contribute to the AWG, at [[User:Zero Linden|Zero Linden]]'s office hours, or on the Wiki, or on SL-Dev or in the [irc://irc.freenode.net/#pyogp irc channel] for the [[Pyogp|Python test client]].

=Activities=
The [[AW_Groupies#Architecture_Working_Group_meetings|main AWG meeting]] is held annually or semi-annually.
We now [[AW_Groupies#In-World_Meetings|meet up to 9 times a week in-world]], counting AW Groupies meeting, Zero's office hours, Which's office hours, Enus's office hours and the [[Pyogp#In_World_Meetings|pygop daily meetings]].

Our main focus these days is on the [[SLGOGP_Draft_1|Open Grid Protocol]] and the [[Pyogp|pyogp Python test harness]] for protocol testing.

Also members are quite active on the wiki and in the SLDEV mailing list.

A public SVN repository is open to all AW Groupies members here:
* http://openmv.org/cgi-bin/viewvc.cgi/archwg/

Contact anyone with root on openmv.org for an account if you are in the AW Groupies group in-world.

==Architecture Working Group meetings==
* [[AWG_Meeting_1|AWG I annual meeting transcript, participants' responses, etc]]
* [[AWG_Meeting_2|AWG II annual meeting transcript, video, participants' responses, etc]]

==In-World Meetings==
===AW Groupies meeting===
Weekly meeting times are:
* Tuesdays, 9:30 AM SLT at [http://slurl.com/secondlife/ThorneBridgeTown/156/129/25| Zha's IBM Island at ThorneBridgeTown]
* Tuesdays, 1 PM SLT at [http://slurl.com/secondlife/Grasmere/171/112/27| Zero Linden's office hours at Grasmere]
* Thursdays, 8:30 AM SLT at [http://slurl.com/secondlife/Grasmere/171/112/27| Zero Linden's office hours at Grasmere]
* Thursdays 11 AM SLT at [http://slurl.com/secondlife/Beaumont/149/44/24| Which Linden's office hours at Beaumont] (often AWG-related these days)
* Fridays 1 PM SLT Pyogp/Enus Linden Office Hours (TBA -starting 11 July)

Meetings are scheduled via the "[http://www.google.com/calendar/embed?src=pdd5mpktklo89bgmfgi076mcc4%40group.calendar.google.com SL AW Groupies" google calendar]"

* [http://www.google.com/calendar/feeds/pdd5mpktklo89bgmfgi076mcc4%40group.calendar.google.com/public/basic XML]
* [http://www.google.com/calendar/ical/pdd5mpktklo89bgmfgi076mcc4%40group.calendar.google.com/public/basic.ics ICal]
* Calendar ID: pdd5mpktklo89bgmfgi076mcc4@group.calendar.google.com
* [http://www.google.com/calendar/render?cid=pdd5mpktklo89bgmfgi076mcc4%40group.calendar.google.com Add to your Google Calendar]

====Meeting Agendas====

Each meeting should have an agenda --- which will be distributed via
* google calendar entry
* in-world notice to the SL "AW Groupies" group
* the [[AW Groupies In-World Meeting Agenda]] wiki page
===OpenSim meeting===
* Tuesdays/Thursdays noon SLT, at Wright Town sim in OSGrid. [http://osgrid.org/index.php?page=home&btn=1 Registration Page]

Set client command line options to:
:-loginuri http://osgrid.org:8002
:-loginpage http://osgrid.org/loginscreen.php
:-helperuri http://osgrid.org/

===[[Pyogp]] Coders daily meeting===
* Mon- Thu, 9:30AM SLT at [http://slurl.com/secondlife/Levenhall/91/208/22 infinity is full of stars] (note AW Groupies weekly meeting conflict)

===Chat Logs===

Chat logs of the in-world meetings are published and accessible via the links below:

* 2007 meetings
:* September: [[AW_Groupies/Chat_Logs/2007-09-28 | 28]]
:* October: [[AW Groupies/Chat Logs/2007-10-01 | 1]] [[AW Groupies/Chat Logs/2007-10-05 | 5]] [[User:Zero_Linden/Office_Hours/2007_Oct_09|9 --Zero's office]] [[AW Groupies/Chat Logs/2007-10-16| 16]]
:* November: [[AW Groupies/Chat Logs/2007-11-06 | 6]] [[AW Groupies/Chat Logs/2007-11-13 | 13]] [[AW Groupies/Chat Logs/2007-11-20| 20]]
*2008 meetings
:* January: [[AW_Groupies/Chat_Logs/AWGroupies-2008-01-08|08]]
:*February: [[AW_Groupies/Chat_Logs/AWGroupies-2008-02-19|19]]
:*April: [[AW_Groupies/Chat_Logs/AWGroupies-2008-04-08|08]] [[AW_Groupies/Chat_Logs/AWGroupies-2008-04-22|22]] [[AW_Groupies/Chat_Logs/AWGroupies-2008-04-29|29]]
:*May: [[AW_Groupies/Chat_Logs/AWGroupies-2008-05-20|20]] [[AW_Groupies/Chat_Logs/AWGroupies-2008-05-27|27]]
:*June: [[AW_Groupies/Chat_Logs/AWGroupies-2008-06-03|03]] [[AW_Groupies/Chat_Logs/AWGroupies-2008-06-10|10]] [[AW_Groupies/Chat_Logs/AWGroupies-2008-06-17|17]] [[AW_Groupies/Chat_Logs/AWGroupies-2008-06-24|24]]
:*July: [[AW_Groupies/Chat_Logs/AWGroupies-2008-07-01|01]] [[AW_Groupies/Chat_Logs/AWGroupies-2008-07-08| 08]] [[AW_Groupies/Chat_Logs/AWGroupies-2008-07-15| 15]]

* [https://wiki.secondlife.com/wiki/Category:Grid_Interoperability_Chat_Logs All Grid Interoperability chat logs]
* [https://wiki.secondlife.com/wiki/Category:AW_Groupies_Transcripts All AW Groupies chat logs]
* [https://wiki.secondlife.com/wiki/Category:Pyogp_Transcripts All Pyogp chat logs]
* [[User:Zero_Linden#Transcripts_of_previous_office_hours|Zero Linden's Office Hour Transcripts]]
* [[User:Which_Linden|Which Linden's Office Hour Transcripts]]
* [http://opensimulator.org/wiki/Special:Search?search=chat+log OpenSim chat logs]
* [[Mono/2008-04-04 | mono beta meeting discussion of het-grid]]

(if you post chat logs, you might want to use the [[User:Dr_Scofield/logtransform|sllog2wiki perl script]] to turn them into a more readable wiki table format ready to copy & paste into the chat log page)

Chat logs of AWGroupies meetings should be summarized on the wiki.

==Viewpoint Advocacy Groups==

[[Viewpoint Advocacy Groups]] - groups to focus on specific requirements.
=== AWG-specific VAGs===

* [[Core Grid Services, Protocols, and Structures VAG]]
* [[Event Scalability VAG]]
* [[Geometry and Physics VAG]]
* [[Live Performances VAG]]
* [[Quality Assurance VAG]]
* [[Scalability VAG]]
=== AWG-related VAGs===
* [[Map_API_VAG]]
* [[Multi-Process Client VAG -- draft]]

=Work-In-Progress=

Work-in-progress wiki pages are architecture pages that are (as the name implies ;-)) work in progress. Once the group has reached consensus that a particular topic is "good-to-go" we'll graduate that page to the [[Architecture Working Group|main AWG page]].

==General Concerns==
* [[Scoping]]
* [[Architecture Working Group Glossary|Glossary]]
* [[Use Cases]]
==Communications==
* [[Initial CAPS seed]]
* [[AWG initial flows]]
* [[AWG flows login]]

* [[Mudata]]
* [[Streamlet]]
===Documenting current protocols===
* [[Pyogp|Python test harness for OGP]]
** [[User:Which_Linden/Office_Hours/2008_May_22| Which Linden office hours 22 May 2008]]
====AWG and citizen pages====
* [[Current_login_protocols]]
* [[Current_Sim_Capabilities]]
* [[Example_protocol_code]]
* [[Hegemons_Login_Analysis#Very_simple_C.23__server]]
* [[User:Gareth_Ellison/Supergrid|Litesim grid interop]]

====Linden Lab pages====
* [[Service_Disruptions|"Satellite's Eye" view of the Second Life architecture from a service disruption POV]]
* [[Message_System_and_Capabilities]]
* [[Viewer_Authentication]]
* [[Viewer_Architecture]]
* [[Protocol]]
* [[LLSD]]
* [[Certified_HTTP_Escrow]]
* [[ImprovedInstantMessage]]
* [[Client_parameters|client command line parameters and stuff]]

====libsecondlife reference pages====
* [http://www.libsecondlife.org/wiki/Login Login page]
* [http://www.libsecondlife.org/wiki/Protocol_%28network%29 Protocol page]
* [http://www.libsecondlife.org/wiki/Category:Packets packets index]
* [http://www.libsecondlife.org/wiki/Movement Movement]

====opensim reference pages====
* [http://opensimulator.org/wiki/Grid_Architecture_Diagram opensim grid architecture diagram]
* [http://opensimulator.org/images/3/3c/OGS1Login_Sequence.jpg login diagram (same general sequence as current LL login)]

=== Future Protocols===
* [[Second_Life_Login_API_Strawman]]
:deprecated in favor of:
* [[SLGOGP_Draft_1 | Second Life Grid Open Grid Protocol (SLGOGP_Draft_1)]]
** [[SLGOGP_Teleport_Strawman]]
*[[Architecture_Working_Group#Design_Documents | Ongoing next generation protocols documentation effort by Linden Lab]]

=== Possible future directions ===
* [http://en.wikipedia.org/wiki/OpenID| OpenID A decentralized single sign-on system]
* [http://en.wikipedia.org/wiki/Yadis| Yardis A digital identity protocol]

==Asset Security==
* [[Protecting content in an open grid]]
==Scaling Issues==
* [[Brainstorming#ANALYSIS:_Region_Subdivision_as_a_scaling_method| Region Subdivision]]
* [[Brainstorming#ANALYSIS:_Scalability_through_reverse_proxies:_the_paravirtual_grid| Reverse Proxies]]
* [[AWG Scalability through per-resident subdivision of the Grid| Resident Subdivision]]
==Other==
* [[Use_Cases#Extended_Capability_Clients|Extended Capability Clients]]

=Thinking-in-Progress=

* Have a look and contribute to the [[Brainstorming|brainstorming]] page.

* It's early days on the [[Multi-Process Client VAG -- draft]], but we would highly appreciate input to help with design choices and direction.

=External Resources=

Stuff of interest to or in connection with the [[AW Groupies]] or the [[Architecture Working Group]]:

* [[Developer_communication_tools|Developer Communication Tools (Linden Lab)]]
* [[Pyogp]] {Linden Labs/ AWG Python-based protocols testing library)
* [http://openmv.org/wiki/Main_Page OpenMetaverse Home]
**[http://www.libsecondlife.org/wiki/Main_Page libsecondlife (libsl) homepage]
**[http://opensimulator.org/wiki/Main_Page opensim homepage]
**[http://openviewer.org openviewer homepage]
*[http://www.osgrid.org OSGrid: open/non-profit OpenSim based grid]
* [http://www.realxtend.org/ realxtend homepage]
* [http://www-03.ibm.com/press/us/en/pressrelease/22428.wss IBM PR re: AWG]

==Mailing Lists==
* [http://wiki.secondlife.com/wiki/SLDev Linden Lab (SLDev)]
* [http://www.libsecondlife.org/wiki/Resources#Mailing_Lists libsecondlife]
* [http://opensimulator.org/wiki/Main_Page opensim]
* [http://lists.berlios.de/mailman/listinfo/openviewer-dev openviewer]

==IRC==
* irc://irc.efnet.net/#opensl
* irc://irc.freenode.net/#opensim * irc://irc.freenode.net/#opensim-dev
* irc://irc.efnet.net/#libsl * irc://irc.efnet.net/#libsl-dev
* irc://irc.freenode.net/#openviewer * irc://irc.freenode.net/#openviewer-dev
* irc://irc.freenode.net/#realxtend (Finnish language but can handle English if needed)
* irc://irc.freenode.net/#pyogp (Python test harness/pyogp Second LIfe library irc)

==Forums==
* [http://groups.google.com/group/realxtend| realXtend google forum]

==Misc==

* [http://blog.signpostmarv.name/2008/01/04/map-api-in-new-location/ discussion of new Map API and related issues]
* [http://wiki.secondlife.com/wiki/Open_Source Open Source Portal] --index to all things Open Source for Linden Lab
* [http://www.cap-lore.com/CapTheory/index.html Capabilities theory and practice]

=Members=

Founder [[User: Zha Ewry|Zha Ewry]]

[[User:Saijanai Kuhn|Saijanai Kuhn]]

[[User:Tao Takashi|Tao Takashi]]

[[User:Tillie Ariantho|Tillie Ariantho]]

[[User:Dr Scofield|Dr Scofield]]

[[User:Burhop Piccard|Burhop Piccard]]

[[User:Vicero Lambert|Vicero Lambert]]

[[User:Morgaine Dinova|Morgaine Dinova]]

[[User:Silicon Plunkett|Silicon Plunkett]]

[[Category:Architecture Working Group]]
[[Category:Grid_Interoperability]]
[[Category:AW Groupies]]

AWG: Cross Domain Trust issues

2008-01-15T20:36:58Z

Zha Ewry: /* The core problems */

=== Cross Grid / Cross Domain Trust Issues ===
[[Image:Cgtd.jpg]]

* Each Major area, A, B, H and P are trust domains. The components within trust each other fully, and don't need to do special work to manage trust and security.

* The domains are informally:
** Service Provider Grids A and B: A large, complete grid, with a full set of utilities, including asset storage, currency, escrow, an instant messaging service, map and geography services.
** Hosting Domain H: A smaller hosting company which allows individual entities to host region simulators, and provides asset storage services in support of these regions. This hoster does not manage agents, or users, but rather serves to provide virtual real estate, and the storage of virtual assets, separate from other grids.
** Private region P: A small region of virtual land, with no utilites or services. It does not directly expose any assets or users to other domains

Note: These are three slices of the functional set which makes up a workable virtual world. There are may others, and we will likely examine them in future sections of this write up. Examples include local copies of land, pure agent domains, pure utility hosting domains, private complete domains. Each of these will introduce additional requirements and use cases.

==== The core problems ====

* Are uuids sufficiently unique for these cases?
* When is it safe to pass an entity to a component outside mytrust domain? (The core issue)
** Note: Textures are already loose in the world, if we send them to clients
* Where do I run scripts?
** Note: the script creator may not want the script exposed to other servers
** Note: A domain provider may not want to run arbitrary scripts, given virus, malware concerns
* Rezzing No-copy entities would cause the entity to leave one domain and enter another
*

==== Some issues ====

AWG: Cross Domain Trust issues

2008-01-15T20:18:20Z

Zha Ewry:

AWG: Cross Domain Trust issues

2008-01-15T20:03:38Z

Zha Ewry: New page: === Cross Grid / Cross Domain Trust Issues === Image:Cgtd.jpg

=== Cross Grid / Cross Domain Trust Issues ===
[[Image:Cgtd.jpg]]

File:Cgtd.jpg

2008-01-15T18:52:50Z

Zha Ewry:

User:Zha Ewry

2008-01-15T18:42:41Z

Zha Ewry: /* AWG musings */ -- Adding cross domain trust stuff

Greetings, I'm an active participant in the [[Architecture Working Group]], an active resident, and an Employee of IBM. This does not not mean, I speak for IBM, except when I very specifically state that I'm doing so. Most of the time, I do not, although clearly my employment affects various of my opinions. If you want to talk to me, I'm in world most of the time, and catch e-mail for SL at zha.ewry@gmail.com.

Participant in [[Architecture Working Group]]. See [[User:Zha Ewry/comments on meeting 1]] for comments on this subject.

=== AWG musings ===

This is a bucket where I toss some ideas I am exploring. Comments deeply appreciated, these are not public consensus pages.

:[[AWG: state melding exploration]]

:[[AWG: Core simulator exploration]]

:[[AWG: Cross Domain Trust issues]]

User:Zero Linden/Office Hours/vote

2007-11-20T21:17:01Z

Zha Ewry:

I have to change the Thursday office hour time. There are two options:
* Move it to Wednesday, still at 7:30 AM -- '''votes:''' 3
* Keep it on Thursday, but move to 8:30 AM -- '''votes:''' 2

Vote by increasing the number on one of those lines by one.

Thanks, Zero

Talk:Geometry and Physics VAG

2007-10-27T16:31:36Z

Zha Ewry: /* Physical Assets (And Geometric) */

= Metadiscussion =
*For now, I think geometry and physics are too closely related to be split. However, I can certainly understand a perspective that there might be two closely related viewpoints here. Geometry really doesn't need material properity information or have to participate in a physics engine. On the other hand, physics really has not meaning at the user level without something to act on. So in the end, I see geometry that has optional physical properties and a single viewpoint the covers both. Do others have thoughts on this? --[[User:Burhop Piccard|Burhop Piccard]] 19:04, 16 October 2007 (PDT)

*I liked the structure of your VAG and so used it as a template for [[Scalability VAG|Scalability]] and [[Quality Assurance VAG|QA]] VAGs ... well done. :-) --[[User:Morgaine Dinova|Morgaine Dinova]] 02:56, 18 October 2007 (PDT)
** Always good to be emulated :-) BTW, I tweaked the usecase part a bit to hopefully give a bit of structure. --[[User:Burhop Piccard|Burhop Piccard]] 06:32, 18 October 2007 (PDT)

* The use of the name VAG is unofficial still. There are issues about it that have gone unanswered as a "group" structure. The use of these "VAGs" in their current state is like force implementation without any design. The concerns are expressed about the VAGs being implemented, but they are not being addressed. If that kind of progress mimics any future software design and implementation, I'd say this already demonstrates that goals won't be followed. I hope that not be the case, and I urge that these VAGs evolve into a methodology that can follow the goals. I think you, Burhop, have put a lot of work into this and it deserves the right attention and implementation. [[User:Dzonatas Sol|Dzonatas Sol]] 07:36, 18 October 2007 (PDT)
** Yes, I saw the discussions but didn't want to sit idle while it gets resolved. If VAG changes to something else I'll be glad to update the pages. If a VAT/VAG methodology becomes more clear I would expect us to line up with this too. I think the core information we are collecting now (i.e. usecases, JIRAs, links, etc.) will keep us busy while some of these organizational issues are resolved (as long as you don't take too long :-) --[[User:Burhop Piccard|Burhop Piccard]] 08:26, 18 October 2007 (PDT)

::* There is no place to put design related jira issues right now. The projects listed in jira.secondlife.com do not have space for the AWG project. I get the hint from LL that they are pleased to incubate this project, but AWG needs to quickly evolve into its own hosted site. That evolution needs design and consensus. Without such design and consensus, these VAGs will continue to use LL's resources to "keep us busy" while the organization needs to be resolved. It appears a few others understand that hint. =) Where will AWG related jira issues get entered? [[User:Dzonatas Sol|Dzonatas Sol]] 08:36, 18 October 2007 (PDT)

* There are some discussions on the content of a VAG/VAT related to the architecture. Essentially, the key point is for the VAG/VAT to be more user than architecture oriented. See http://wiki.secondlife.com/wiki/Talk:Viewpoint_Advocacy_Groups for more information. --[[User:Burhop Piccard|Burhop Piccard]] 15:58, 21 October 2007 (PDT)

= List of concerns addressed by this viewpoint =
* Burhop, does "Efficient communication of Geometric and physical properties" include client communication efficiency? From the scalability perspective, I'm interested in anything related to reduction or optimization of server->client object traffic, including negociated reductions in that traffic for example. --[[User:Morgaine Dinova|Morgaine Dinova]] 01:59, 22 October 2007 (PDT)

** Yes, I think thats a primary driver. One aspect of the viewpoint (in my opinion) is that we want richer and more detailed geometry with more motion and interaction without a perception of sluggishness in the system. The two work against each other so how do you trade off?

::I think there are a several scalability axes here.

::1.) How does the viewer scale as its geometry engine is overloaded?
::2.) How does this affect the graphics hardware?
::3.) How does this affect the network and comunication betweewn servers?
::4.) How does this scale to different configurations of computer hardware, viewers, network speeds.

::Thinking just of server->client, suppose we have a high power gaming machine as a client. We may want to pump more information to it. On the other hand, if we have a low end computer or a cell phone (gasp!), we will want to optimize the pipeline by sending less/different information. --[[User:Burhop Piccard|Burhop Piccard]] 12:26, 24 October 2007 (PDT)

= View Point Modification =

There have been a number of VAG and AWG organizational discussions and I think it might be time to reformulate this VAG in light this.

One key thought was to be more user oriented than architecture oriented with an example being a "Builder VAG". So perhaps a "Physical Content creation" VAG makes better sense for this. I would expect this to include bringing in 3D geometric assests from other VWs, user created and professional tools, file formats, etc. It would also include scalability issues (see above). I'm thinking this better follows the sucessful "sculpted prim" work which has engaged people so well. Thoughts? --[[User:Burhop Piccard|Burhop Piccard]] 09:43, 25 October 2007 (PDT)

= Use Case =
I've tried to add some one-line use cases to give better feel for what the VAG might be. These are either my own or ones I've discussed with SL content creators. I'm flexible about changing these. Some of the Sculptie Dev people have had some excelent ideas.--[[User:Burhop Piccard|Burhop Piccard]] 16:18, 26 October 2007 (PDT)

== Physical Assets (And Geometric) ==

The {{AWG|Geometric Asset}} idea is a really good interest for this. I actually see how that could be integrated with MediaWiki with some other ideas on here to bring the efforts of unrelated groups more in-line.

The physical attributes, I had a concern about them. I'm pretty sure there has to be a separate interest for this even if it gets combined together on the record. If there was no virtual world, there would be no concern. There are, however, physics as in math and physics as in real world cause and effect. We can map out real world events with math or like data structure, but to communicate the distinction is hard because of how the features and terms just meshes together tightly. I'm not sure if a wedge is really needed. Instead, COLLADA used "digital asset" for a term. I suggest we use an "AWG Digital Asset" like name to create the distinction of more pure geometric assets and the combined form of all interest that gets put together on the record. That way, in one aspect, we can say the physical attributes are metadata to the {{AWG|Geometric Asset}}.

*** [[User:Dzonatas Sol|Dzonatas Sol]] 06:41, 27 October 2007 (PDT)

I think this is a misunderstanding of the usage of meta-data. In general, the software engineering term refers to extrinsic things about a data element, such as access control, or encoding format, not intrinsic content. The physical attributes of an asset, are going to be part of the core model of that asset, not a description of the asset. In general, meata-data is stuff we attach to a resource, object or such to further describe it orthogonally to its primary description.

-- [[User:Zha Ewry|Zha Ewry]] 09:31, 27 October 2007 (PDT)

Talk:Second Life Grid Glossary

2007-10-26T20:53:05Z

Zha Ewry: /* Avatar */ (Add discussion sections for Avatar Delegate and Avatar Delegate Child)

'''Where did the old content go?'''

Don't worry. Its all down below. In order to try and make this a little more focused I am putting in a section in here for each term and section in the glossary. This ''may'' make the page a little more usable. I suppose the next step would be a sub-page per term, but I am resisting that. Feel free to pull still current comments UP into the subsections. I'll try to grab some of that shortly, but. I think authors are probably better suited to that.

==== Agent ====
'''content merged from seperate page to avoid wiki sprawl'''

This is [[User:Dzonatsas Sol]]'s material
= Specifications =

An ''Agent'' is a software resource which represents some portion of a user in the virtual world. Agents are hosted in agent servers. An agent may cause an avatar to be instantiated on behalf of a user.

Agents:

* Mediate the user's message traffic
* Mediate the user's asset inventory
* Act as a focal point for the user's access to services in other domains
* Act as a focal point for the user's access to utilties
* Act to report the user's avatar's location in the Virtual World to other parts of the system

Agents do not:

* Store persistent assets (They are stored in asset servers)

Agents are not:

* The software resource which represents a user's avatar inside a region simulator. (Tho we need a name for that.)

This definition is different from the current (pre agent/region domain split) use of the term agent Second Life. Currently agents are hosted on the simulator where the user's avatar resides, and handle these tasks as well as mediating the avatar's connection to the client. The term agent, in general is overloaded, and is it possible that another, more specific term would be appropriate here.

= Brainstorming =

* The envisaged [[Project_Motivation|massive scaling]] requires new forms of item organization, search, and access to cope with vast expansion. The current inventory mechanism is already stretched right now, so this issue needs early design attention.
* it should be possible to manage inventories of all your agents under one identity. The idea is to e.g. being able to move items from one inventory to another
* some organisation providing agents should be able to define on which regions an agent is allowed to connect, what he/she can do with object in their inventory
* an agent domain should be able to have certain inventory pools which might be shared among agents (like the library in SL today)
* it should be possible to import and export friends lists or groups of friends
* it should be possible to maintain a friends list among various agent domains (related to import/export maybe but as protocol function)
* it should be possible to copy inventory from one agent domain from another if the object structure is compatible.
* an agent needs to provide various methods of verification
* an agent domain needs to define presence information among an agent's friends list. This should even be possible among various agent domains.
* Each agent needs to be able to define certain permissions on what other agents or groups of agents are allowed to see about him (online status, identity information, etc.)

==== possible restrictions between regions and agents ====

* An agent domain should be able to define on which regions an agent is allowed to connect
* An agent domain should be able to define which objects are allowed to be rezzed on which region (e.g. company objects only on company regions etc. This might be related to object pools as described above).
* A region might allow only certain agent domains to connect
* A region might allow anybody to connect but the rights of that agent might be limited depending from where it comes and e.g. which verification mechanism the agent provides.
* Standard specification of rights/permissions in a serialisable form that can be edited by the viewer and uploaded to an authorative per-domain server?

==== Architecture ====

==== Architectural desriptions and views (ADV) ====

==== Asset ====

* (temp note): ''We need some clarity here, and elsewhere in the glossary between a Web Services description of resources such as an asset, and an in use description. If we view all assets as having URLs and a singular place in an asset server where the definitive copy of the asset exists, then we need to separate that from the potentially many places where copies of that set of information may be cached and used.'' -- [[User:Zha Ewry|Zha]]

* Ah.. Actually, if we wish to make a distinction between the asset's data, and its meta-data, then, we have the asset, which would be what we "get" from the URL, and the meta-data, which we seperate from the core item, in one of several ways. There was a nice bit of discussion of this in Zeros office hours on October 18 [[User:Zero Linden/Office Hours/2007 Oct 18|transcript]] -- [[User:Zha Ewry|Zha]] October 18, 2007, 5:42 PDT

* you meant Oct 18, i think. corrected to that effect [[User:Dr Scofield|Dr Scofield]] 03:18, 23 October 2007 (PDT)

* updated the asset entry. question: how does an asset reference come into existence? we need to get the flow for that. [[User:Dr Scofield|Dr Scofield]] 03:18, 23 October 2007 (PDT)

* ''asset is currently under discussion on sldev'' -- [[User:Dr Scofield|Dr Scofield]] 00:19, 18 October 2007 (PDT)
Heart, by your desire, fresh fantasy, deep and pure. You requested that
I tell you the fantasy and how I feel. Not merely a description of it,
but the deepest ways it impacts me. Therefore...

'''Transfered from another page, to ensure we are all on the same page'''

= Abstract Data Structure =

{{AWG|Asset}}:
* {{AWG|Identity}} Property
* Intellectual Property
* Permissive Property
* Metadata

= Specifications =

* Note: The core asset-data is a form of intellectual property; however, one or more assets may allude to one or more combined forms of intellectual property. Another words, the abstractness allows for the one-to-one relation, one-to-many relation, many-to-one relation, and the more implicit many-to-many relation.

* The {{AWG|Agent Store}}s and the {{AWG|Region Store}}s are the primary databases for {{AWG|Asset}}s, which have an {{AWG|Identity}} Property as the primary key, and that key is in a form of a UUID.

* {{AWG|Asset}}s also exist in secondary databases, which perform similar to the primary databases. A cache for {{AWG|Asset}}s is a secondary database.

* The properties and metadata provide the mechanism to access, cache, copy, modify, or distribute the {{AWG|Asset}}s between databases.

* Each {{AWG|Asset}} has only one primary database such that there are never two or more primary databases for a given {{AWG|Asset}}.

* An {{AWG|Asset}} is '''tangible''' if it has a primary database.

* An {{AWG|Asset}} is '''transient''' if it has no primary database. For instance, an {{AWG|Asset}} originates from a secondary database.

* A '''tangible {{AWG|Asset}}''' that alludes to another '''tangible {{AWG|Asset}}''' is '''referential'''.

* A '''transient {{AWG|Asset}}''' that alludes to another {{AWG|Asset}} is '''abstract'''. Note: there a distinct difference between the abstract data type and an abstract {{AWG|Asset}}.

* A '''tangible {{AWG|Asset}}''' that alludes to a '''transient {{AWG|Asset}}''' is '''irrational'''. Note: irrational {{AWG|Asset}}s create complex sanity checks for them to be rationalized if possible.

* An '''{{AWG|Asset}} pointer''' is not an {{AWG|Asset}} itself; it is merely a pointer to an {{AWG|Asset}}. Note: The {{AWG|Asset}} pointer is more implementational than architectural, but we specify it here so that any API design may use it.

= Brainstorming =

* allow objects to only be able to rez on certain regions (adds to the agent's restrictions)
* AND/OR limit object rezzing to specific groups of objects (give region owner ability to control what content is allowed in their regions)
* allow assets to be transferred between agent domains
* allow assets to be accessed from multiple agent domains
* allow truly distributed asset storage
* Think beyond the limitations of prims and sculpties by allowing items made in 3d modelling software to be directly imported onto the grid. Other online virtual 3D environments allow this.
* allow licenses to be attached to objects such as CC licenses etc. Could be some license field in the protocol.
* possibility to add proxies for assets. People running their own servers might want to reduce disk access on the sim machines by adding a second machine with a proxy. Proxies improve response time on webservers with heavy access a lot, so it should work for sims with high traffic, too.
* allow geometry standards to be used for objects. SL doesn't have a tool like Sketchup and so needs to be more open to other existing geometry creation tools (sculpties are too insufficient).
* It is likely that *'''no'''* geometry standards will ''ever'' be sufficient. Therefore, don't waste time on defining geometry standards. Instead, focus on designing a way of making the suite of available geometry standards '''extensible''' simply through ''a posteriori'' addition, without requiring ''a priori'' definition.

* It is possible to implement asset storage in a completely distributed way
** Assets need not be stored in fixed locations (such as in the 'home' grid of the creator, for example)
** A completely Peer-to-Peer (P2P) storage protocol is possible
:: It's worth pointing out that P2P is the ''only'' topology that scales with the number of participants in the world. Other topologies have useful properties and get us part of the way (eg. private distributed authoritative world servers fronted by non-authoritative commercial big-iron caches), but ultimately P2P has no real challanger.
** To be successful it would have to retain many of the properties of the current 'fixed' storage schemes
*** Available: Since the individual physical storage providers in a P2P network can't be trusted, a great deal of redundancy would be required to make it unlikely an asset would ever become unavailable
*** Secure: Assets would need to be encrypted using strong PKI where appropriate (for example, so you can be sure nobody but the primary key holder (/ capability holder) can view your script source or edit your object). For the same reason, no asset should be stored in-whole at any single physical location (hence requiring the collusion of a large number of parties to even assemble the encrypted form of an asset in order to mount a cryptographic attack, unless the 'directory' of storage addresses for the asset has also been compromised). Obviously this wouldn't apply to the 'public' form of an asset (e.g. script bytecode, pre-optimized object mesh etc.).
*** Persistent: Some mechanism to control the lifetime of assets may be needed
**** Given the pace of storage technology progress, it may be possible to just keep every asset ever created (ride the wave of progress)
**** If limited asset lifetimes are needed, some kind of distributed garbage-collection algorithm could be employed
**** What would happen to assets that remain accessible but never 'accessed' for long periods of time? (We don't want the 'virtual data archaeologists' who research the 22nd century in one thousand years from now to keep running into cases of assets that are no longer available just because a long time has passed without 'access'!)
**** Will it be possible to delete assets/accounts someday?
** This may be a hard problem to solve properly now, but just designing an architecture with it in mind and then implementing something similar to the fixed scheme utilized now would leave the possibility open of implementing the more general case in the future.
*** Lets avoid a repeat of the mistake made in the 'design' of the www, where public pages are often stored on servers owned/leased by their creators and routinely lost for the future (save the efforts of the way-back-machine etc).
* Assets should support being signed (and notarized)
** Perhaps they should even allow arbitrary meta-data to be attached to them by their creators (or anyone with perms) and accessed via scripts
* Assets should be raw data.
** Asset type, permissions, creator, watermark, etc would be meta-data.
** Any kind of meta-data could be added and used or ignored as needed.
* How will a region be able to accept an alien object from another system's inventory, or an inventory to accept an object from a foreign region?
** Would an upload fee make sense for transferring objects to different grids? Who will pay it? The creator? The first one who bought it and travels to the other grid?
** If so, how would that fee be determined for a completed object?
** Would some grids (or domains if you'd prefer) be able to reject items from other domains on a permission basis?

=== Decentralized assets ===
* How does a locally-run, disconnected grid provide texture/animation uploads or anything of use without the centralized system to accept the upload fee, read and update the user's inventory, or receive the new asset information?
** Local database backend stores all the local content, any content on the remote asset servers with appropriate permissions (perhaps a "can download" flag?) can be downloaded for use on a local stand-alone grid
** Any new assets, or locally modified assets can be re-uploaded
** "Can download" must imply "Can modify" for practical reasons (DRM will not work!)

''' More material brought onto the common page '''
The identifier for an asset OUTSIDE a specific domain (trust domain, region domain, region, etcetera) is not a UUID, it's a URL. The form of the URL is unspecified, except that the host-part is the address of the asset server responsible for that asset, and that the asset can be manipulated with POST and GET commands passing standard URI-encoded parameters.

Within a domain the identifier of an asset is a UUID that is unique within that dmain and other domains sharing the same trust environment.

Assets hosted in other domains are mapped to UUIDs in a manner that is up to the domain. The expected technique is to create a new instance of the asset, containing a location property with the URI of the original asset, with all other properties copied from theoriginal, and with the asset data possibly cached in the local asset server.

*** -- [[User:Argent Stonecutter|Argent Stonecutter]] 19:11, 23 October 2007 (PDT)

The inside/outside view of the identifier is true for what you say with and without the URL. The technique to create a new instance all depends on if the properties allow. A non-copiable tangible asset may have only a single instance in the entire grid, but there may be several referential assets to allude back to the single non-copiable instance. (See: [[#The Chair]])

*** [[User:Dzonatas Sol|Dzonatas Sol]] 19:31, 23 October 2007 (PDT)

What benefit do you get by using only a UUID inside the domain? It seems like it'd be simpler to just use a unique URL as the identifier all the time. I guess you can save on bytes if the uuid->url translation is trivial, but why bother? That way you don't have to check to see whether the asset is in-domain and thus have to apply the transformation, or out-of-domain and thus do not. Admittedly, debating this point is sort of icing-on-a-tea-crumpet, but, hell, I'd be in favor of moving Second Life's internals to use all urls, all the time.

Also, I do not understand what all this 'alluding' means. Refers to? Contains a url for?

*** [[User:Which Linden|Which Linden]] 22:52, 23 October 2007 (PDT)

Ah, I see where that can get confused about the URL. It is within the Asset's database record that appears bit more of an implementational detail to also store the URL. Given a potential 3rd normal form, one would not store the URL along with the asset unless the URL is part of the IP. I don't totally disagree, but I do question if the identity property of the asset record needs to hold more than a UUID for at least this cycle of the model to design. It still remains abstract enough to allow something other than only a UUID. I've heard hints about the "icing" (I've even suggested similar), and I surely don't want to obstruct the possibility. =)

"Alludes" or an "allusion" is less constrained than being "referred to" (a direct mention), while an allusion is more indirect, like passed by reference. An allusion may evaluate to an object, but the actual reference may be indeterminate by the value of the allusion alone. In implementation (discretely), an object can only make direct reference to other objects, but the structure of the references creates the allusion. For example, an oxygen atom and two hydrogen atoms can directly link to each other, but that linked structure alludes to a discrete molecule. It is too simple of a concept in order for it to be patentable, unlike many popular aspect-oriented languages that can be patented. =)

*** [[User:Dzonatas Sol|Dzonatas Sol]] 07:40, 24 October 2007 (PDT)

= The Chair =

This where the "chair" question came about. What happens if the chair is made up of copiable and non-copiable assets where each piece of the chair being separate intellectual property and each IP owned individually by different people. Let's say the chair was manufactured by buying the seat separately from the base, and separately from the feet, and separately from the textures, so the chair then was assembled together by a person who bought all those pieces from different people. The assembled chair then is set to sell. How does one buy it? What are the steps to perform this? How does each step look in the databases for where each asset exists?

*** [[User:Dzonatas Sol|Dzonatas Sol]] 19:31, 23 October 2007 (PDT)

= Primary Database Thoughts =

* In a decentralized system, there is always the potential net splits to occur. Methods need to be developed to prevent irrational assets or even broken referential assets. For example, one could require the complete form of an intellectual property be stored all in a single primary database with all related assets that constitute that form instead of being allowed to exist in multiple primary databases. [[User:Dzonatas Sol|Dzonatas Sol]] 23:07, 22 October 2007 (PDT)

* It is obvious that movement of tangible assets from one primary database to another primary database needs a cHTTP basis to communicate the move. [[User:Dzonatas Sol|Dzonatas Sol]] 23:07, 22 October 2007 (PDT)

* One way to avoid irrational assets is to allow secondary database be local to a primary database such that the secondary database stores abstract assets instead of the attempt to create irrational assets. I've done a similar scheme like this before on a very small scale, and I already know it is test cases with abstract assets are not as simple as to allow irrational assets. There are, however, less redundant sanity checks are needed with abstract assets locally to the primary database, and it reduces a load on the primary database with assets that would become tangible but actually remain transient. [[User:Dzonatas Sol|Dzonatas Sol]] 23:07, 22 October 2007 (PDT)

== Domains ==

A domain is a group of hosts that may contain assets or instances of assets that share a trust model. They may be a trust domain (the largest contiguous set of hsost sharing a trust model), a region domain (from the original Linden documents), a single server. A uniform domain is one that shares a closer relationship than the AWG model specifies... the Linden grid is a homogenous domain. A non-uniform domain is one in which the AWG model must be used for interoperation between at least some members.

Within a uniform domain, assets are normally referred to using UUIDs.

Between uniform domains, assets are referred to using URLs. THe host part of the URL is the DNS address of the host responsible for that asset (eg, a region or an asset server). The path is unspecified, it merely has to be unique. URI-encoded attributes may be appended to request particular properties, iterate over properties, and (through POST operations) update properties. A standard URI for creating a new asset must be available on any asset host.

An asset may have multiple instances. Each instance contains a COPY of the asset properties that the requestor is allowed to have, a reference (location property) to the original asset, and possibly a cached copy of the asset data. When an instance is created from another instance, the location property of the original asset may be retained in the new instance, or the second instance may become a new independant copy of the asset with a permanent local copy of the asset data... that is, the distinction between instances and assets is flexible.

Details of enforcing intellectual property rights are primarily of interest for groups implementing non-uniform trust domains. Permissions and other rights metadata are only informational between trust domains. This is not to say that IP law does not apply, but that trust domains implementing different trust models can not be compelled to implement all trust models. It is anticipated that most domains will implement an asset property indicating that the asset is not to be transferred into another trust domain.

*** - original content above from article space

This is good information. I like to see how this can be worked into other design documents such as {{AWG|Region Domain}}, {{AWG|Agent Domain}}, and even the components of those domains, like {{AWG|Region Store}}s or {{AWG|Agent Store}}s.

*** [[User:Dzonatas Sol|Dzonatas Sol]] 19:39, 23 October 2007 (PDT)

==== Avatar ====
Does the Avatar represent and agent, or a user? I think a user. The agent is a software construct which permits the user to interact with other portions of the system.

==== Avatar Delegate ====

==== Avatar Delegate Child ====

==== Component ====

==== Domain ====
* I replaced the label of the link to "AWG Domain rationale discussion" by "Domain rationale discussion". The use of "AWG Domain" creates terrible confusion and also conflicts with LL's use of the term. The page itself should be renamed too, but that's better done by its creator. --[[User:Morgaine Dinova|Morgaine Dinova]] 09:49, 20 October 2007 (PDT)

* The architecture proposed by LL also created a point of confusion in its use of "Organization Domains" ... there's some sort of dimensional incompatibility there with the use of "Domain" in "Agent Domain" and "Region Domain". [[Talk:Multiple_Domains|I wrote a little about this topic]] back in September when I looked at the diagrams from the first meeting. Organization is better thought of as an attribute within this architecture, because it is so orthogonal to the other domains. What's more, it's a composite attribute with many aspects: for example, a server could belong to company A, provide resources for the group B, and be located in colo C. Which is the Organization domain? There is no single answer. "Organization Domain" isn't a very cohesive concept. --[[User:Morgaine Dinova|Morgaine Dinova]] 10:11, 20 October 2007 (PDT)

==== Meta Data ====

==== Permissions ====

==== Region ====

==== Region Domain ====

==== Resource ====

==== Scalability ====

==== Service ====

==== Simulation (sim) ====

==== Stakeholder ====

==== Use Case ====

==== User ====

==== Utility ====

==== Viewer ====

==== Viewpoint ====

==== See Also ====

==== Pre 10-19-2007 content ====

* The title needs changing to something less specific, like "Glossary", because '''Viewer''' is certainly not a component of a grid. --[[User:Morgaine Dinova|Morgaine Dinova]] 09:29, 25 September 2007 (PDT)

* Added Services and Utilities to the list -- [[User: Zha Ewry|Zha Ewry]] 9/26/2007

* I didn't want to define these since they reference the Linden "implementation" but it would be good to define what is meant by "Central Utilities" and Identity, location, and currency.--[[User:Burhop Piccard|Burhop Piccard]] 17:55, 3 October 2007 (PDT)

* '''Page renaming'''
: As has been discussed on various occasions in AWGroupies and elsewhere, the parent page '''Components and Roles''' has evolved, and as a result it is no longer named appropriately. I would change it to one of the names that have been suggested (eg. AWG_Glossary) if I knew how to migrate its namespace tree as a unit, ie. including Talk, history etc, but I don't know how to do that. Anyone? --[[User:Morgaine Dinova|Morgaine Dinova]] 02:32, 12 October 2007 (PDT)

* did that. refactored page into [[IEEE 1471]] page and glossary page while i was at it. [[User:Dr Scofield|Dr Scofield]] 09:12, 12 October 2007 (PDT)
::* Thanks, that's hugely better. :-) --[[User:Morgaine Dinova|Morgaine Dinova]] 03:57, 13 October 2007 (PDT)

* Reformatted page to use small '====' section headings instead of labels, so that we can edit them one at a time, more scalable. :P --[[User:Morgaine Dinova|Morgaine Dinova]] 03:57, 13 October 2007 (PDT)

* DrS, I've reexpressed your additions under "Architecture" as '''architectural descriptions''' for some randomly-named "''message flow viewpoint''" (maybe it should refer to ''protocols'' or whatever, change as required). The terms for "documents" are in flux --- '''ADV''' for "''architectural descriptions and views''" is just a placeholder, although it seems to work well. Zero has already delivered those nice graphic '''ADV'''s that cover 2 or 3 different viewpoints, although the concerns aren't all that easy to identify in them precisely because they're all thrown in together.
:: The central idea (as in IEEE-1471, which is a synthesis of a billion approaches prevalent in industry), is that "'''The Architecture'''" doesn't in fact exist outside of our heads, and is only communicated in specialised views which reflect the concerns and bias of specific parties.

:: I am forced to admit that I find the bullet point above, simply, at some level incomprehensible. The architecture we are defining is not some platonic ideal. It is a set of formal, normative specifications which to the best of our human capacities specify precisely and unambiguously how to build a conformant implementation. The specifications, hold no viewpoint, they have no biases. They may result from the fusion of many viewpoints, the clash and resolution of many stakeholders, but the architecture is deeply and fundamentally the normative documents which define it and '''nothing else.''' Reifications and realizations of the architecture may deviate from the specifications, but that doesn't change the architecture at all. - [[User:Zha Ewry|Zha]]
::* That's not how the industry sees it Zha. The viewpoint-based approach of IEEE-1471 isn't something radical and new, it's just a distillation (and a very simple non-prescriptive one) of many standard approaches to defining architecture in use throughout computing. Even Zero has effectively used this method in his architectural diagrams, which express the architecture from 2 or 3 different viewpoints. There is actually no other way, no matter how hard you try: your document will always end up describing how the architecture addresses the concerns of a given viewpoint. If you claim that your "normative documents" cover everything salient in the architecture, then all you've done is put all those viewpoint-based descriptions together in one lump. You're not really disagreeing. :-) --[[User:Morgaine Dinova|Morgaine Dinova]] 00:32, 14 October 2007 (PDT)
:::* More importantly though, it allows us all to work separately/grouped but towards a common goal, instead of bickering about what should appear on a one single central document. And an added benefit: it can make it easier for LL to back-port ideas into SL1, since the concerns and solutions will be nicely factored out. Evolution is an important goal, as Zero has made clear. --[[User:Morgaine Dinova|Morgaine Dinova]] 00:41, 14 October 2007 (PDT)

* I added a use case defintion as used with AWG. A "use case" is a bit different since its not really part of the architecture but one of several tools for coming up with an architecture. I still think it goes here because I've tried to narrow the definition a little bit to the AWG context and avoid some of the common misuses of the term. --[[User:Burhop Piccard|Burhop Piccard]] 15:17, 15 October 2007 (PDT)
::* Very useful, as we bandy this term around a lot. :-) It begs for a definition of "user" now, and I can't find a useful one. --[[User:Morgaine Dinova|Morgaine Dinova]] 21:28, 15 October 2007 (PDT)
::* I removed the first external link, to Wikipedia, as it widened the possible meanings rather than narrowing them. The whole point of this AWG glossary is to make us all speak the same language, as the Tower of Babel effect was leading to some unnecessary arguments. External links act in the opposite direction in this case. I left in your second Wikipedia reference, but I don't think that that line helps at all, as it just says "throw in the kitchen sink". If you could revise the line to not need the link, that would be helpful. :-) Perhaps follow the form you set in [[Early_Stage_Usecase_Template|minimal template]] and add a [[Final_Stage_Usecase_Template|detailed template]]? --[[User:Morgaine Dinova|Morgaine Dinova]] 21:58, 15 October 2007 (PDT)

::: Yes, I'd like to create a final state template but its a bit trickier as it needs to be more tailored to the system. I don't think the link is really needed except as a reference for people wanting more information. I'll try to reword it. --[[User:Burhop Piccard|Burhop Piccard]] 09:35, 17 October 2007 (PDT)

* Zha, excellent addition to architecture: you've reconciled the differences through "point in time". Works for me. :-) --[[User:Morgaine Dinova|Morgaine Dinova]] 21:28, 15 October 2007 (PDT)

* I added the "domain" term but I don't think its quite right. Can someone with a better understanding update it? --[[User:Burhop Piccard|Burhop Piccard]] 11:09, 16 October 2007 (PDT)

* In general, skimming the glossary, it feels like we need to get a little more disciplined about how we toss around phrases. For example, "meta data" is defined in a way that only refers to meta data on assets. There are other places in the architecture where we might well want to talk about meta-data, and in fact, depending on exactly how we define and use asset, the meta-data, may or may not always be attached to the asset. Other examples which concern me are resource, where we provide an extremely scalabality centric perspective on resource, which, for example, ignores the common web notion of a resource. We describe, Identity as both an utility and a component. We describe one specific domain, and describe it, in fact in a way which contradicts Zero's diagram, which has two seperate regions domains, both operated by Linden Labs.
I can just go in and start hacking on these, but, I'm hoping the people who posted them will take a careful look at them first. -[[User:Zha Ewry|Zha]] 7:59 pm PDT, October 17, 2007

Second Life Grid Glossary

2007-10-26T20:51:04Z

Zha Ewry: Add Avatar Delegate, and Avatar Delagte Child, to help understand the split in function, as the agent breaks up into the agent and region portions

A glossary of terms with specific meanings within the project, defined so that discussions can be concise and misunderstandings fewer. We also encourage you to take a look at the [[IEEE 1471]] article on designing an effective system architecture which addresses all of the project goals.

Please note that this glossary is specific to the SL Architecture Working Group and is intended for use only within the context of Second Life. The definitions are not expressed in a generic manner, and should not be interpreted that way.

==== Agent ====
'''This is the user portion of the current notion of a SL agent. We may wish to name it '''user agent''' in distinction from the portion of the current notion of a SL agent which remains connected to the user's avatar, which one might call an '''avatar agent''' or "avatar proxy'''

:An Agent is a software resource which represents some portion of a [[Architecture_Working_Group_Glossary#user|user]] in the virtual world. Agents are hosted in agent servers. An agent may cause an avatar to be instantiated on behalf of a user. An Agent mediates, for the user, by acting as the software endpoint in the system which invokes various services within the web at the user's direction, generally via the user's client.

for a tentative example of flows between Clients, Agents and Services, see [[AWG worked agent example]]

:Agents:
:* Mediate the user's message traffic
:* Mediate the user's asset inventory
:* Act as a focal point for the user's access to services in other domains
:* Act as a focal point for the user's access to utilities

:Agents do not:
:* Store persistent assets (They are stored in asset servers)

:Agents are not:
* the portion of the current SL agent which remains in the region simulators, this is the Avatar Delegate.

==== Architecture ====
: An abstraction (or mental model) of the SL system which corresponds to its system design. It is revealed through architectural descriptions and multiple views ('''ADV''').
: Alternatively, the end product of a set of processes yielding a set of normative documents which define compliance to the architecture. This is not, inherently in opposition to the first definition as it captures the architecture at different points in its evolution.

==== Architectural descriptions and views (ADV) ====
: Documents which describe (textually and/or graphically) how the various pieces of the SecondLife system fulfil their expected goals. More precisely, ADVs express in detail how the system architecture is conformant with the concerns expressed in viewpoints. Some examples:

: For a ''message flow viewpoint'', ADVs describe how system components interact with one another by describing their relations, protocols and message formats.

: For a ''scalability-oriented viewpoint'', ADVs describe the relevant system resource pools and their capacities, the flow paths and choke points, the bandwidth of links and access mechanisms, the means of expanding capacity, and the analysed scalability of key elements.

: For a ''client capability viewpoint'', ADVs ennumerate and detail the client-related capabilities, client-server capability negociation mechanisms and protocols, means of activating capability negociation, and client-side capability state transitions.

==== Asset ====

: An entity which can be transferred from agent to agent or from agent to region or from region to agent. It can be something like an object, texture, sound, link, landmark, and so forth.
: Architecturally, we destinguish between an '''asset''' and an '''asset reference''':
:* an asset is a blog of binary data, some (small) amount of meta data, a URL and a UUID. the meta data contains things like content-type.
:* an asset reference contains a reference to the asset and properties such as permissions. asset references are inventory items.

==== Avatar ====
: The representation of user in a region of virtual world space.

The avatar is the visual presence of the user within the virtual world. We distinguish this from the various data structures and software resources used to support the avatar, so that we can talk about how the avatar is projected into the virtual world, separate from the software components which perform that task.

==== Avatar Delegate ====

: The endpoint within a region simulator that acts as delegate for the avatar. This is the software addressable, component of the system which allows other services, and the client to interact with the avatar's presence in the region simulator.

An Avatar Endpoint:
* Acts as the connection point between a client and the region simulator hosted avatar
* Acts as the locus for the avatar's sensing in the region simulator
* Follows the avatar's location within the region simulator

Note: This is the portion of the current agent, which remains in the region simulator when the agent components, such as inventory and IM management have been migrated to the agent, hosted on an agent server in the SL notion of an agent domain.

==== Avatar Delegate Child ====
: the endpoint within a region simulator that acts as the delegate for an avatar in a adjacent region, for purposes of sensing, and being heard, within the adjacent region. This might also be thought of as the agent's camera, in the region.

An Avatar Delegate Child:
* Acts as the point at which an avatar senses activity in region adjacent to its current region
* Provides a connection between the user's client, and the region hosting the avatar delegate child.

==== Component ====
: A logical composition that is proportional to a whole. In the domain architecture of the AWG, these compositions include viewpoints and views. In software and hardware, these include modules, units, and devices.

==== Domain ====
:A partition of architectural resources, and services. A domain can be characterized by its membership and the set of properties that the members share. In Internet usage, a domain is commonly tied to DNS namespace, with the shared property being name resolution. In terms of our architectural structure, domains share a set of properties, and gain some benefit from this distinction.

:The architecture may expose domain membership, and the properties which define the domain through a standard web service.

:Examples of domains might include

:* All the region servers supporting Linden Lab's mainland
:* All the corporate hosted servers supporting XYZ Co's private islands. (Which might include Region, Asset, and Utility serviced specific to XYZ co.)
:* All the servers and services within HostingCorps trusted firewall.

:In each case, the partition permits the members to act differently with respect to each other, than members outside the partition.

:To understand the rationale for this definition, see [[AWG Domain rationale discussion|Domain rationale discussion]].

==== Meta data ====
: Meta data is data ''about'' data: it describes the data and its properties. In the architecture discussions we use ''meta data'' for [[#Asset|assets]].

==== Permissions ====
: A kind of license digest that specifies what rights the creator of an asset grants to a user of that asset (or what rights she doesn't want to grant) [see also [[Protecting content in an open grid]]]

==== Refactored Composition ====
: Refactored Composition refers to a technique to arrange the factors of a composition such that the composition is more orthogonal to a new model. This term, or like terms, is often mistakenly used in expression to just rewrite, remake, or recompose the factors, or lesser constituents, within the same model the composition already exists.

==== Region ====
:Some space. It can have any form. It can be grouped together with other regions. It is part of a region domain.

==== Region Domain ====

:Set of regions sharing one or more properties, permitting them to be grouped into a domain.

:Examples of region domains might include:

:* All of the regions forming a continent run by a service provider
:* All of the regions hosted by the XYZ corporation
:* All of the regions which support a new release of a physics engine

==== Resource ====
* [REST]: software entity, or stored value which can be addressed via a [http://en.wikipedia.org/wiki/Uniform_Resource_Locator URL] One basic design point of the architecture is that it follows RESTful web practices.

* [Scalability]: Any finite architectural component or property or behaviour that is subject to exhaustion or which can become a bottleneck to system performance. Resources are the primary focus in designing for scalability. Examples: client-server bandwidth, agent pool depth, database access mechanism, locks, transaction times, utilities, services.

==== Scalability ====
: The ability of a system to grow effectively ''in a given dimension'' in proportion to the amount of resource or capacity provided. The given dimension is often associated with a related dimension. A specific system may attempt to be ''scaled'' by adding resources, but this is effective only if the system is ''scalable''. Example: scalability in the number of avatars at an event, viewed against the size of the user population, in proportion to the hardware allocated.

==== Service ====
: A Web Services invocable resource which performs some task on behalf of a region

==== Simulation (sim) ====
: A computation over time that mimics real world events within a part of the virtual world.

==== Stakeholder ====
: Anyone who has a ''technical'' viewpoint that impacts on AWG work on system architecture.
: Non-technical viewpoints exist and have validity, but do not fall within the current scope.

==== Use case ====
: A technique used to capture the requirements of a system or architecture. Use cases avoid technical jagon although this often depends on the scope and actors of the use case. Generally, the archtectural terms in this glosary are valid (i.e. Identity, Viewer, Service) while specific technical terms are not (C++, REST, XML). Detail of a AWG use case can vary:

:* A '''brief''' use case consists of a few sentences summarizing the use case.
:* A '''casual''' use case consists of a few paragraphs of text or a [[Early_Stage_Usecase_Template|minimal template]], summarizing the use case.
:* A '''fully dressed''' use case is a formal document based on a detailed template with fields for various sections; and it is the most common understanding of the meaning of a use case.
: For a more general understanding of use cases please see [http://en.wikipedia.org/wiki/Use_case the Wikipedia article].

==== User ====
: An person in control of an agent.

==== Utility ====
: A Service, or collection of services which provides a utility which does not manifest as a region, agent or avatar within the virtual world. Examples: Currency, Identity, Asset Storage, Messaging, Presence, Topology Management.

==== Viewer ====
: Currently, a monolithic client-side program which establishes communication with system servers and displays a visual image of the virtual world. It usually controls an agent represented by an avatar, eventually inside a region. As client programming evolves, the viewer ''per se'' may become only a client subprogram which deals with 3D rendering and UI handling exclusively, assisted by other subprograms.

==== Viewpoint ====
: A set of related concerns about the architecture, and the representations or views used to describe the architecture to address those concerns. Examples: Client viewpoint, Client UI viewpoint, Functional viewpoint, REST Services viewpoint, Scalability viewpoint, Region Scalability viewpoint, Network viewpoint, Manpower viewpoint.

= See Also =

* [[Glossary]]
* [http://pascal.computer.org/sev_display/search.action Software and Systems Engineering Vocabulary]

[[Category:Architecture Working Group]]
[[Category:AWGroupies]]

Talk:Architecture Working Group

2007-10-25T21:45:44Z

Zha Ewry: Created highlights, will group and organize next. Propsal to limit design documents to design documents

{{Talk}}

== Keep front page clean ==

* The main namespace needs cleaning up. A number of recent additions are very clearly just personal [[Brainstorming]], so that's where they should go. In particular, new proposals identified with the proposer's name certainly don't belong on the AWG front page. It has the eye of the world on it. --[[User:Morgaine Dinova|Morgaine Dinova]] 21:09, 15 October 2007 (PDT)

* I've removed the suffix "(proposal)" from Viewpoint Advocacy Groups because of the widespread support that VAGs have received, not to mention that some VA Groups are already defined and operational. --[[User:Morgaine Dinova|Morgaine Dinova]] 04:23, 18 October 2007 (PDT)

== Materials ==
* The entries in our AWG Glossary are slowly being factored out of the actual Glossary page, and placed instead into the Description section of instances of a template. This is in principle a good thing, because it ensures that definitions appearing in more than one place cannot get out of step with each other.

* However though, for some reason, that template was named Design Document Template, as if the instances of the template document the design. They don't document the design, they merely document the terms used in the design, and in that they have a useful role. The architectural design process is not a matter of merely defining terms though, but a matter of composing well defined terms into an architecture. The template should be called Term Definition Template, so that its instances become Term Definitions.

* I've changed the reference to the glossary terms page appropriately (under '''Materials'''), but the template itself needs to be renamed also, as well as all of its instances. While "Design Document" is "just a name", choice of that name totally changes the semantics of the design process, which shouldn't have been done without discussion. Alternatively, we could throw all the VAGs and all the other resource pages in there as well, since they're all "design documents". 
--[[User:Morgaine Dinova|Morgaine Dinova]] 12:03, 21 October 2007 (PDT)

* They are all "design documents," but the template itself is only for one category of them to make sure the descriptions of a model are mappable to each other. Other definitions that are not in the scope of the model are better put in the "Term Definitions" as you suggest. [[User:Dzonatas Sol|Dzonatas Sol]] 12:22, 21 October 2007 (PDT)
:* OK, so I guess that you're saying that it's correct to stick all the VAGs documents and all other design documents on that page too, since it's simple labeled "AWG Design Documents" and doesn't refer to the fact that it's used only for glossary definition. Should we ram all of LL's design proposal documents in there as well (they're certainly "design documents"), plus all of our extensive design analysis documents, as well all of the VAG documents that impact on design? They're all "design documents" after all.
:: The problem isn't so much the name of the template (which could have many uses), but the fact that what should be Term Definitions have inherited the name of the template, and so has the page that gathers them together, and this conveys the wrong idea entirely, as if this were where Design is happening. It's not. Everything we write is a Design Document to the same extent as mere Term Definitions are. The naming is just not correct, and it can derail the various design groups into ensuring that their "important" documents end up there otherwise they will not be considered central "Design Documents". That wouldn't help teamwork.
:: I have a solution, apart from renaming the actual documents to "Term Definition", which is what they were. The solution is to delete the page that gathers them together. After all, if it's just for gathering glossary terms together, we already have that --- the [[Architecture_Working_Group_Glossary|glossary]] page! Why do we need a second one?
:: Alternatively, if you are intending to make that page a true index of all design documents, then everything will have to go in there, and your template is certainly not an applicable constraint since VAGs won't employ that template, and nor will countless other design documents. --[[User:Morgaine Dinova|Morgaine Dinova]] 12:44, 21 October 2007 (PDT)

* I've entered rationale on the [[AWG Design Document Template]] at the same time you entered the above comment. I believe that answered your questions, concurrently by coincidence. Let's further the discussion on its [[Talk:AWG Design Document Template|talk]]. [[User:Dzonatas Sol|Dzonatas Sol]] 13:01, 21 October 2007 (PDT)

== Separate policy from mechanism ==

I'm not sure where to put this in the wiki, but I would advise awareness of "The Art of Unix Programming". In particular, "Separate policy from mechanism" should be rule #1:

http://catb.org/~esr/writings/taoup/html/ch01s06.html#id2877777

[[User:Seg Baphomet|Seg Baphomet]] 23:14, 21 September 2007 (PDT)

:This is as good a place as any. It's not altogether clear that X is a fantastic example to use to make this point. The line between "policy" and "mechanism" is rarely clear cut. For example, cut and paste between X applications is still a crapshoot (even in 2007) because I guess "how to handle the clipboard" was a policy (?) rather than a mecahnism. At the same time, "all applications must be network transparent" was baked in as mechanism, not policy (which, in the 1980s, was a pretty dubious choice, and creates optimization challenges to this day).

:I'll freely admit I could be very wrong about these specific deficiencies in X. My point is merely that I'm not sure that this provides a great rule, and I worry that being too orthodox on this point can lead us to [http://c2.com/cgi/wiki?PrematureGeneralization premature generalization]. -- [[User:Rob Linden|Rob Linden]] 13:03, 22 September 2007 (PDT)

:X11's architecture was well designed for what it was designed for... which was researching window systems. Putting the policy in the application rather than the display subsystem was appropriate for that goal. Other display systems have implemented policy in required libraries (the Xerox/Apple approach) and in the display manager (Amiga Intuition, Plan 9's 8½) or in code pushed to the display from the application (NeWS and to a lesser extent Display Postscript and HTML).
:Separating policy and mechanism is really just a special case of the general concept that layering should be guided by responsibilities, and that the responsibility for a given capability shouldn't be shared between layers unless necessary. ESR tends to be a dogmatic and does not seem to have had a particularly broad experience with technologies, so tends to pull examples in that don't really illustrate his points very well and stick to them when people suggest other examples might work better, but that doesn't mean his points are not, when analysed and generalised, worth paying attention to. -- [[User:Argent Stonecutter|Argent Stonecutter]] 11:12, 10 October 2007 (PDT)

:: I support separation of policy from mechanism as well, but I won't provide a quote to avoid opportunities for counter-quotes. :-)

:: Seriously, there are two very down-to-earth engineering reasons why you separate policy from mechanism at every opportunity.
::* Firstly, ''you don't know what the required policy will actually be'', except vaguely, so you have to keep it separate or else you'll be hacking around with the mechanism code, and that's extremely bad for stability. This is especially important given the scary numbers envisaged by Zero and the total uncertainties presented by a massively scaled and massively distributed system.
::* And secondly, when you don't separate policy from mechanism early, then you are deferring that refactoring for a rainy day. It will ''always'' be harder and costlier to do it later, and often that difficulty and extra cost results in the work never being done at all, and hence the system limping along in its compromised state for ages.
:: The only really strong reason for lumping policy and mechanism together is in very time-critical code where every cycle counts, and really we're not in that ballgame at all here. I support a clean separation at this design stage. --[[User:Morgaine Dinova|Morgaine Dinova]] 08:54, 24 September 2007 (PDT)

== [[Proposed Architecture]] page extremely hard to find ==

Current revision of this page buries the [[Proposed Architecture]] page in a way that's really, really difficult to find. What's the best way to make sure that people can find this. -- [[User:Rob Linden|Rob Linden]] 13:40, 23 October 2007 (PDT)
:* Isn't that whole page structure somewhat curious? The only really good solid section seems to be Materials. I don't mind much personally, but since this is the world-facing point of entry, perhaps it merits just a little bit of extra polishing. --[[User:Morgaine Dinova|Morgaine Dinova]] 19:32, 23 October 2007 (PDT)
:: Agreed. What can we nuke/move to talk pages/etc? There is far more material than Linden Lab can provide effective oversight for right now. Zero apparently requested breaking things up (see Dz's comment on [[Category talk:AWG Design Document]]), and that may be helpful. I'd like to keep things out of the main namespace that don't represent the consensus view. Links to personal opinion pages should be on the Talk page, not on this page. -- [[User:Rob Linden|Rob Linden]] 18:07, 24 October 2007 (PDT)
::* Oh dear, we seem to have grown even more personal pages indexed from the front one, it's becoming a blog roll. This is going in the wrong direction. --[[User:Morgaine Dinova|Morgaine Dinova]] 09:10, 25 October 2007 (PDT)
::* Aye Rob. In fact, some of those pages don't even deserve to be in Talk here, since they're not discussing the main page in question. I hesitate to suggest adding even more to Brainstorming, but that's exactly what some of them are. (Brainstorming is a good thing, but needs to be done in the right place.)
::* "Oversight" is probably the wrong word to use, as Linden Labs is actually an ''enabler'' for community work here, which is ultimately more powerful. As Zero says, LL will not necessarily take on board everything that comes out of AWG --- some aspects may end up implemented only by third parties that interoperate with SL. --[[User:Morgaine Dinova|Morgaine Dinova]] 09:24, 25 October 2007 (PDT)

* I created a very small "highlights" section to bring the key stuff to the top. I'll next start chopping away at pushing some of the sprawl into clustered sub pages. I am also going to try to re-capture anything which is essentially definition, back to the glossary for know. I'll put discussion/brainstorming stuff into either talk pages, or rationale pages, linked off the definitions.
* As design documents would imply documents with designs in them, which would be a) actual designs, not collections of brainstorms and thoughts, and b) group consensus, formed here, or via mailing list, or in world, I am proposing that we pull that category for now, and recapture the content in either brainstorming pages, personal thoughts pages, or when they are definitional anchored out of the glossary. This should cut down on wiki sprawl, and also keep the navigation through the core documents clearer.

-- [[User:Zha Ewry|Zha Ewry]] 14:41, 25 October 2007 (PDT)

Talk:Architecture Working Group

2007-10-25T21:41:51Z

Zha Ewry: /* Proposed Architecture page extremely hard to find */

{{Talk}}

== Keep front page clean ==

* The main namespace needs cleaning up. A number of recent additions are very clearly just personal [[Brainstorming]], so that's where they should go. In particular, new proposals identified with the proposer's name certainly don't belong on the AWG front page. It has the eye of the world on it. --[[User:Morgaine Dinova|Morgaine Dinova]] 21:09, 15 October 2007 (PDT)

* I've removed the suffix "(proposal)" from Viewpoint Advocacy Groups because of the widespread support that VAGs have received, not to mention that some VA Groups are already defined and operational. --[[User:Morgaine Dinova|Morgaine Dinova]] 04:23, 18 October 2007 (PDT)

== Materials ==
* The entries in our AWG Glossary are slowly being factored out of the actual Glossary page, and placed instead into the Description section of instances of a template. This is in principle a good thing, because it ensures that definitions appearing in more than one place cannot get out of step with each other.

* However though, for some reason, that template was named Design Document Template, as if the instances of the template document the design. They don't document the design, they merely document the terms used in the design, and in that they have a useful role. The architectural design process is not a matter of merely defining terms though, but a matter of composing well defined terms into an architecture. The template should be called Term Definition Template, so that its instances become Term Definitions.

* I've changed the reference to the glossary terms page appropriately (under '''Materials'''), but the template itself needs to be renamed also, as well as all of its instances. While "Design Document" is "just a name", choice of that name totally changes the semantics of the design process, which shouldn't have been done without discussion. Alternatively, we could throw all the VAGs and all the other resource pages in there as well, since they're all "design documents". 
--[[User:Morgaine Dinova|Morgaine Dinova]] 12:03, 21 October 2007 (PDT)

* They are all "design documents," but the template itself is only for one category of them to make sure the descriptions of a model are mappable to each other. Other definitions that are not in the scope of the model are better put in the "Term Definitions" as you suggest. [[User:Dzonatas Sol|Dzonatas Sol]] 12:22, 21 October 2007 (PDT)
:* OK, so I guess that you're saying that it's correct to stick all the VAGs documents and all other design documents on that page too, since it's simple labeled "AWG Design Documents" and doesn't refer to the fact that it's used only for glossary definition. Should we ram all of LL's design proposal documents in there as well (they're certainly "design documents"), plus all of our extensive design analysis documents, as well all of the VAG documents that impact on design? They're all "design documents" after all.
:: The problem isn't so much the name of the template (which could have many uses), but the fact that what should be Term Definitions have inherited the name of the template, and so has the page that gathers them together, and this conveys the wrong idea entirely, as if this were where Design is happening. It's not. Everything we write is a Design Document to the same extent as mere Term Definitions are. The naming is just not correct, and it can derail the various design groups into ensuring that their "important" documents end up there otherwise they will not be considered central "Design Documents". That wouldn't help teamwork.
:: I have a solution, apart from renaming the actual documents to "Term Definition", which is what they were. The solution is to delete the page that gathers them together. After all, if it's just for gathering glossary terms together, we already have that --- the [[Architecture_Working_Group_Glossary|glossary]] page! Why do we need a second one?
:: Alternatively, if you are intending to make that page a true index of all design documents, then everything will have to go in there, and your template is certainly not an applicable constraint since VAGs won't employ that template, and nor will countless other design documents. --[[User:Morgaine Dinova|Morgaine Dinova]] 12:44, 21 October 2007 (PDT)

* I've entered rationale on the [[AWG Design Document Template]] at the same time you entered the above comment. I believe that answered your questions, concurrently by coincidence. Let's further the discussion on its [[Talk:AWG Design Document Template|talk]]. [[User:Dzonatas Sol|Dzonatas Sol]] 13:01, 21 October 2007 (PDT)

== Separate policy from mechanism ==

I'm not sure where to put this in the wiki, but I would advise awareness of "The Art of Unix Programming". In particular, "Separate policy from mechanism" should be rule #1:

http://catb.org/~esr/writings/taoup/html/ch01s06.html#id2877777

[[User:Seg Baphomet|Seg Baphomet]] 23:14, 21 September 2007 (PDT)

:This is as good a place as any. It's not altogether clear that X is a fantastic example to use to make this point. The line between "policy" and "mechanism" is rarely clear cut. For example, cut and paste between X applications is still a crapshoot (even in 2007) because I guess "how to handle the clipboard" was a policy (?) rather than a mecahnism. At the same time, "all applications must be network transparent" was baked in as mechanism, not policy (which, in the 1980s, was a pretty dubious choice, and creates optimization challenges to this day).

:I'll freely admit I could be very wrong about these specific deficiencies in X. My point is merely that I'm not sure that this provides a great rule, and I worry that being too orthodox on this point can lead us to [http://c2.com/cgi/wiki?PrematureGeneralization premature generalization]. -- [[User:Rob Linden|Rob Linden]] 13:03, 22 September 2007 (PDT)

:X11's architecture was well designed for what it was designed for... which was researching window systems. Putting the policy in the application rather than the display subsystem was appropriate for that goal. Other display systems have implemented policy in required libraries (the Xerox/Apple approach) and in the display manager (Amiga Intuition, Plan 9's 8½) or in code pushed to the display from the application (NeWS and to a lesser extent Display Postscript and HTML).
:Separating policy and mechanism is really just a special case of the general concept that layering should be guided by responsibilities, and that the responsibility for a given capability shouldn't be shared between layers unless necessary. ESR tends to be a dogmatic and does not seem to have had a particularly broad experience with technologies, so tends to pull examples in that don't really illustrate his points very well and stick to them when people suggest other examples might work better, but that doesn't mean his points are not, when analysed and generalised, worth paying attention to. -- [[User:Argent Stonecutter|Argent Stonecutter]] 11:12, 10 October 2007 (PDT)

:: I support separation of policy from mechanism as well, but I won't provide a quote to avoid opportunities for counter-quotes. :-)

:: Seriously, there are two very down-to-earth engineering reasons why you separate policy from mechanism at every opportunity.
::* Firstly, ''you don't know what the required policy will actually be'', except vaguely, so you have to keep it separate or else you'll be hacking around with the mechanism code, and that's extremely bad for stability. This is especially important given the scary numbers envisaged by Zero and the total uncertainties presented by a massively scaled and massively distributed system.
::* And secondly, when you don't separate policy from mechanism early, then you are deferring that refactoring for a rainy day. It will ''always'' be harder and costlier to do it later, and often that difficulty and extra cost results in the work never being done at all, and hence the system limping along in its compromised state for ages.
:: The only really strong reason for lumping policy and mechanism together is in very time-critical code where every cycle counts, and really we're not in that ballgame at all here. I support a clean separation at this design stage. --[[User:Morgaine Dinova|Morgaine Dinova]] 08:54, 24 September 2007 (PDT)

== [[Proposed Architecture]] page extremely hard to find ==

Current revision of this page buries the [[Proposed Architecture]] page in a way that's really, really difficult to find. What's the best way to make sure that people can find this. -- [[User:Rob Linden|Rob Linden]] 13:40, 23 October 2007 (PDT)
:* Isn't that whole page structure somewhat curious? The only really good solid section seems to be Materials. I don't mind much personally, but since this is the world-facing point of entry, perhaps it merits just a little bit of extra polishing. --[[User:Morgaine Dinova|Morgaine Dinova]] 19:32, 23 October 2007 (PDT)
:: Agreed. What can we nuke/move to talk pages/etc? There is far more material than Linden Lab can provide effective oversight for right now. Zero apparently requested breaking things up (see Dz's comment on [[Category talk:AWG Design Document]]), and that may be helpful. I'd like to keep things out of the main namespace that don't represent the consensus view. Links to personal opinion pages should be on the Talk page, not on this page. -- [[User:Rob Linden|Rob Linden]] 18:07, 24 October 2007 (PDT)
::* Oh dear, we seem to have grown even more personal pages indexed from the front one, it's becoming a blog roll. This is going in the wrong direction. --[[User:Morgaine Dinova|Morgaine Dinova]] 09:10, 25 October 2007 (PDT)
::* Aye Rob. In fact, some of those pages don't even deserve to be in Talk here, since they're not discussing the main page in question. I hesitate to suggest adding even more to Brainstorming, but that's exactly what some of them are. (Brainstorming is a good thing, but needs to be done in the right place.)
::* "Oversight" is probably the wrong word to use, as Linden Labs is actually an ''enabler'' for community work here, which is ultimately more powerful. As Zero says, LL will not necessarily take on board everything that comes out of AWG --- some aspects may end up implemented only by third parties that interoperate with SL. --[[User:Morgaine Dinova|Morgaine Dinova]] 09:24, 25 October 2007 (PDT)

::* I created a very small "highlights" section to bring the key stuff to the top. I'll next start chopping away at pushing some of the sprawl into clustered sub pages. I am also going to try to re-capture anything which is essentially definition, back to the glossary for know. I'll put discussion/brainstorming stuff into
either talk pages, or rationale pages, linked off the definitions.

::* As design documents would imply documents with designs in them, which would be a) actual designs, not collections of brainstorms and thoughts, and b) group consensus, formed here, or via mailing list, or in world, I am proposing that we pull that category for now, and recapture the content in either brainstorming pages, personal thoughts pages, or when they are definitional anchored out of the glossary. This should cut down on wiki sprawl, and also keep the navigation through the core documents clearer.

[[User:Zha Ewry|Zha Ewry]] 14:41, 25 October 2007 (PDT)

Architecture Working Group

2007-10-25T21:17:31Z

Zha Ewry: Pulled key things to the top for visbility

{{Template:AWG_NavBox}}
[[Image:slarch.jpg]]

I have gathered my tools and my charts,
My plans are finished and practical.
I shall roll up my sleeves — make Second Life over.

==Goal==

Discuss, design and implement a scalable and open architecture for the future Second Life Grid.

Create an architecture and set of specifications which will form the basis for:

* The next generation SecondLife Grid
* World Wide Web scale hosting of Virtual World Content
* Multiple inter-operable implementations of the complete architecture (Metaverse creation)
* Allowing Individuals and Enterprises to host content, agents and virtual land

== Highlights ==

* [[Proposed Architecture|High Level Architecture proposed by Linden Lab]] (see the starting point)
* Participate by contributing:
** In the wiki
** Throught [[Viewpoint Advocacy Groups]] (topic oriented focal points)
** Via SLDEV [http://wiki.secondlife.com/wiki/SLDev sldev mailing list] and use tags like [ARCH] and [AWG] in the subject line.
* [[AWG_Process|Process]] (proposal)
* [[Architecture Working Group Glossary|Glossary]]

'''See below for many more details'''

== Participating ==
Membership in this group is open. Start contribution to the work, and you become a member.
* Contribute to the materials and documentation in this wiki --- a lot of material is being drafted and discussed in the [[AW Groupies]] section (also, see below).
* Join the [http://wiki.secondlife.com/wiki/SLDev sldev mailing list] and use tags like [ARCH] and [AWG] in the subject line.
* Meet with others for technical discussions: [[User:Zero Linden|Zero Linden's]] office hours, [[AW Groupies]].

==Meetings==
Formal meetings will likely be held 3-4 times/year and located in Second Life to facilitate broad participation. Meetings will be coordinated on [[SLDev]]. Group members are encouraged to self-organize smaller meetings to move forward particular work areas and discuss hot topics as needed.

* Meeting 1
** [[ArchWG_Mtg_1_Agenda|September 13th 2007, Meeting 1]]
** [[Workitems for Meeting 1]]
** [[2007-09-13 Arch WG Minutes]]
* [[Chatlog from 2007/09/16]] (Gigs, otakup0pe and Tao_T talk about possible forms of regions etc.)
* [http://taotakashi.wordpress.com/2007/09/24/second-life-grid-architecture-meetup-transcript/ Transcript and Slides from Tao Takashi's informal meetup on 2007/09/23]
* [[In World Chatlogs]]
* [[AW Groupies]]

See also: [[User:Zero Linden|Zero Linden's office hour transcripts]]

==Materials==

* [[Project Motivation]]
* [[AWG_Process|Process]] (proposal)
* [[Architecture Working Group Glossary|Glossary]]
* [[:Category:AWG Design Document|Design Documents]]
* [[Use Cases]]
* [[Brainstorming]]
* [[Scoping]]
* [[Viewpoint Advocacy Groups]]

==Architecture Proposals==
* [[Proposed Architecture|High Level Architecture proposed by Linden Lab]]
* [[Hyperplanes]]
* [[Tedds stand-alone script engine|Tedds stand-alone script engine proposal]]

==Individual Reviews and Feedback==

* [[ Zha's comments on meeting 1]]
* [[AWG: Zha's Desiderata for evaluating the proposed design]]
* [[ Tree's comments on meeting 1]]
* [[Diva Canto's Review]]
* [[Mic's Feedback]]
* [[Views of the Gareth]]
* [[Omei Turnbull's thoughts on asset domains]]

==Discussions==

* [[DRM, IP and permissions]] (from the mailing list)
* [[Initial CAPS seed]]
* [[AWG initial flows]]

<noinclude>
[[Category:Architecture Working Group]]</noinclude>

Scalability VAG

2007-10-25T14:57:11Z

Zha Ewry: /* Members (Stakeholders) */

: This is an early draft so scope and focus are still fairly open. Please add comments to the [[Talk:Scalability VAG]] if you have slightly different concerns so that we can try to converge on a common viewpoint. Where appropriate, this discussion could expose the need for related sub-VAGs in this area.

= Purpose =

The '''Scalability''' '''V'''iewpoint '''A'''dvocacy '''G'''roup exists to provide input for architectural design that is focused on the expressed [[Project Motivation|Project Motivation]] of the project and the banner motto of AWG: "Making the Grid a Scalable Place".

More specifically, the Scalability VAG is concerned with identifying all important dimensions of scalability, determining the relevant scaling pressures as numerically as possible, establishing both the end limits and realistic near-term goals for scalability and scaling, and ensuring that these concerns are addressed in the evolving architectural design.

The Scalability VAG is a technical VAG.

==== The Scalability VAG is an umbrella VAG ====
In view of the magnitude of the task described above, it is expected that the Scalability VAG will devolve into separate VAGs each concerned with one dimension of scalability, as well as other specialized VAGs. To this end:
# This Scalability VAG will seek to avoid specialization, to avoid overlap with sub-VAGs.
# This Scalability VAG will provide references, analysis and tools as a resource for sub-VAGs.
# Where other VAGs have viewpoints that ''imply'' the need for scalability but lack technical expertise or interest:
#* This Scalability VAG will adopt the relevant scalability concerns, possibly in a sub-VAG.
#* This Scalability VAG will assist towards conformance of the architecture with those concerns of that VAG.

See the [[Architecture Working Group]] and the [[Viewpoint Advocacy Groups]] for more information.

Known sub-VAGs:
:* [[Event Scalability VAG]]

=== Areas addressed by this viewpoint ===
* Identification of all [[Scalability_VAG#Dimensions of scalability|dimensions of scalability]] relevant to this platform.
* Scalability of the new system architecture in all dimensions of population growth:
:* For each dimension identified:
:::* determination of the relevant growth metrics
:::* assessment of current constraints on scalability
:::* consideration of new designs with improved scalability
:::* detailed scalability analysis of all design proposals
:::* measurement and presentation of levels of conformance
* Specific elements of maintenance scalability, especially in regard to graceful degradation:
:* Dynamic scalability of system architecture in response to:
:::* anomalous growth of total population over short periods of time
:::* variation of concurrent online users over the daily and weekly cycle
:::* anomalous population dynamics resulting from media events and special holiday periods
:::* unplanned resource malfunction and equipment failure
:::* withdrawal of services or resources for maintenance.
* Tools and methods by which scalability of designs and systems can be evaluated and documented.

=== Areas not addressed by this viewpoint ===
* Scalability of interoperation is not addressed at this time, namely the rate and ease or otherwise with which worlds and grids can interconnect with the SL grid and vice versa.
* Functional scalability is not addressed at this time, for instance the rate and ease or otherwise with which worlds and grids can add new service definitions while maintaining interoperability.

= Scalability VAG Glossary =
The following terms and abbreviations are defined for this viewpoint with the purpose of reducing repetition and providing joint terms of reference for stakeholders of this VAG. A small handful of terms overlap with those in the [[Architecture_Working_Group_Glossary|main AWG glossary]], but this is only to localise this VAG's lookups and to avoid cluttering up the main glossary with detailed scalability examples and explanations.

==== Multi-Factor Scalability Limit (MFSL) ====
: A scalability limit which results from the combination of two or more partially disjoint or simpler scalability limits, ''ie.'' '''PPSL'''s. It is of high practical value in specifying project scalability goals in a concise manner and without engaging further in-situ scalability analysis or discussion.

: Example: under a (hypothetical) premise that dislike of crowds reduces event attendance by half when events attract more than 1,000 participants, then a '''PPSL''' scalability end-limit of 20,000 would be reduced to an '''MFSL''' of 10,000 participants.

==== Population-Proportional Scalability Limit (PPSL) ====
: A scalability limit which results from direct arithmetic scaling of a current value along a given dimension in proportion to growth in a related dimension. This is a ''raw'' scalability limit, in the sense that it is ''as far as possible'' unaffected by any other up-scaling nor down-scaling factors. As such, it provides a well-defined element for use in scalability analysis rather than an actual target for scalability.

: Example: the end limit of scalability in the number of avatars at an event, calculated from the projected growth in user population (2 bn) versus the current level of interest in attending a given event (100) given the current population (10m), yields a '''PPSL''' of (2000*100/10) = 20,000 people interested in attending that event.

==== Resource ====
: Any finite architectural component or property or behaviour that is subject to exhaustion or which can become a bottleneck to system performance. Resources are the primary focus in designing for scalability. The resource-based approach to highly scalable design involves removal of barriers to massive replication of resources, in conjunction with providing a massively scalable access mechanism for concurrent acquisition of those resources. The potential scalability of a system is however limited by additional factors, especially interdependency of resources, secondary resource exhaustion, etc.

: Examples: client-server bandwidth, agent pool depth, database access mechanism, locks, transaction times, utilities, services.

==== Scalability ====
: The ability of a system to grow effectively ''in a given dimension'' in proportion to the amount of resource or capacity provided. The given dimension is often associated with a related dimension. A specific system may attempt to be ''scaled'' by adding resources, but this is effective only if the system is ''scalable''. Example: scalability in the number of avatars at an event, viewed against the size of the user population, in proportion to the hardware allocated.

= Source of Viewpoint =
No existing sources for this viewpoint have (yet) been sought. This viewpoint is however highly reusable, and therefore existing sources are very likely to exist and should be investigated.

Sub-VAGs that wish to reuse this viewpoint are required to specify the extent of reuse through inclusion and exclusion.

= General concerns addressed by this viewpoint =

The foregoing scalability viewpoint is founded on a few broad concerns:

:* That all important dimensions of scalability be identified, to avoid costly surprises further downstream.
:* That identified dimensions of scalability be grounded in fact and basic arithmetic as far as possible.
:* That end limits of scalability be accompanied by well-reasoned near-term and mid-term projections.
:* That scalability of the architectural design be accompanied by concrete proposals for achieving it.
:* That all proposals are subject to effective scalability analysis and ceiling estimation.
:* That design costs and impact on other VAGs and aspects of the project be assessed.
:* That the concerns expressed in this viewpoint be addressed in a conformant system architecture.

= Dimensions of scalability =
The following 4 population-related dimensions of scalability are captured from [[Project Motivation]] as an initial basis for this VAG. The estimates in dimensions 1-3 and the '''PPSL/MFSL''' (see [[Scalability_VAG#Scalability VAG Glossary|our glossary]]) numbers are likewise only an initial basis:

# Scalability of world extent:
#:* 60 million regions (probably more) (60 was mentioned [http://wiki.secondlife.com/wiki/User:Zero_Linden/Office_Hours/2007_Sep_18 here] by Zero Linden )
# Scalability of world population:
#:* 2 billion users (''rationale for initial estimate required'')
# Scalability of concurrent users:
#:* 50 - 100 million concurrency across all client types (''rationale for initial estimate required'')
# Scalability for events (concurrent users in a single region):
#:* PPSL: 20 thousand per region ([[Talk:Project_Motivation|calculated proportional to world population]])
#:* PPSL: 100 thousand per region ([[Talk:Project_Motivation|calculated proportional to concurrent users]])
#:* MFSL: ''analysis to be done''

= Specific concerns within this viewpoint =
Here we define the specific concerns relevant to each dimension of scalability:

= Use Cases =

= Proposals and Analysis =

= Organization =

== Joining ==

Anyone with an interest in this Viewpoint is welcome to join. You should join the [[AW_Groupies]] group in Second Life.

== In world meetings ==

We meet once a week in-world and more if people are available.

Also members are active on the wiki and in the SLDEV mailing list.

Meetings Schedule:

=== Meeting Agendas ===

* TBD

=== Chat Logs ===

* TBD

= Architectural Descriptions/Views used to express this viewpoint =
This section identifies:
# the general form or representation of [[Architecture_Working_Group_Glossary#Architectural descriptions and views (ADV)|ADV]]s required to express the viewpoint
# the elements within such ADVs which will be used to express the viewpoint
# how these elements within such ADVs map to the concerns of this viewpoint
# the traceability to viewpoint concerns required for conformance with the viewpoint.

None decided.

= Tools employed by this VAG =

* Normal wiki textual and graphic representations are expected to be sufficient for this VAG.
* Programmed tools are expected to be developed for scalability testing and measurement.

= External Links =

= VAG wiki structure =
There is a balance to be found between excessive length of pages and excessively fine partitioning. This VAG is a technical one, which means that cohesiveness of subject is especially important, and partitioning should be driven mainly by the need for clarity rather than by simple length. Suggestions for improving partitioning under pressure of growth (highly on topic here) are very welcome, including but not limited to sub-VAG devolution.

= Members (Stakeholders) =
''Please note that the Scalability VAG is a non-hierarchical VAG in every respect, without exception. Any tags supplied with names are purely informational. Stakeholder ordering is alphabetical.''

:[[User:Morgaine Dinova|Morgaine Dinova]] 02:21, 18 October 2007 (PDT) - Founder, analyst
: [[User:Zha Ewry|Zha Ewry]] 07:57, 25 October 2007 (PDT) - Middleware and core architecture scalability, WEB scale approach advocate

[[Category: AW Groupies]]
[[Category: AWG Design Document]]

User talk:Dzonatas Sol/AWG Prim

2007-10-25T01:57:01Z

Zha Ewry: Prims, as they exist in SL

Prim, as used in SL, is well defined here [[Primitive]]

Prims do not, as far as I can see, in any way, shape or form utilize an agent. Prims live inside the region simulators, where they have bounding boxes for the Havok phsyics simulation, and a set of graphics data which is used when they are rendered on the client.

* Prims can be rezzed into a region simulator

* Prims participate in phyical simulation

* Prims have graphical data which is used in rendering

* Prims can be stored as assets, in asset servers.

* Some prims contain an inventory of assets.

* Some prims are in a linkset

* Some prims are attached to avatars

:Prims will be encoded and shipped as parts of architectural protocols.
[[User:Zha Ewry|Zha Ewry]] 18:57, 24 October 2007 (PDT)

Category talk:AWG Design Document

2007-10-25T01:08:58Z

Zha Ewry: /* Wiki sprawl */ Keep discussion on talk pages, and don't fork, don't make it hard to edit

* Any danger of actually discussing what you're doing here Dzon? The sections are no longer editable after what you've done. --[[User:Morgaine Dinova|Morgaine Dinova]] 13:09, 21 October 2007 (PDT)
* Please talk to us Dzon, don't just unilaterally turn the wiki into some random HTML junk. When we press Edit, we're meant to be able to edit, not get dumped into some obscure piece of HTML magic. This is what the Talk page is for, to warn of major changes and get them agreed. Or should I revert? --[[User:Morgaine Dinova|Morgaine Dinova]] 13:39, 21 October 2007 (PDT)

== Wiki sprawl ==

It appears as though many of these pages are sprawled out versions of existing content. For example, we now have a [[AWG Agent Domain]] and an [[Agent Domain]] page. Why a whole new set of pages here? -- [[User:Rob Linden|Rob Linden]] 18:24, 23 October 2007 (PDT)

* I did make a note about it here: [[AWG_Design_Document_Template#Goals]]. Also see, Zero's office hour transcripts: [[User:Zero_Linden/Office_Hours/2007_Oct_18]] (~ 7:48 and further). You'll notice his concern with the AWG articles. I started to use [[Brainstorming]] as a first candidate to organize discussions by interest to an aspect of the model. I also wanted to make sure we could separate the previous model with the AWG model, so that terminology does not get confused as easily. Perhaps, I didn't make that part with the actions clear. With the example, [[Agent Domain]] included all topics about the Agent Domain, which include the Agent Stores, Agent Hosts, Agent Services, and much more. Each one if specified in detail on a single page can create a really long page, as we started to see when an older version of [http://wiki.secondlife.com/w/index.php?title=Brainstorming&oldid=35936 Brainstorming (v35936)]. It appeared to sprawl out at length over many topics and subjects even though it was a single page. I noticed a lot of the same interest touched on in various areas on the entire page and also on other pages. There was no way to just pull up a wiki page that relates to a more concise interest and find a flow of discussion about it. Also, I constantly saw the concern that people wanted to jump into some form of implementation. The design documents, with the basic template followed, uses the normal wiki abilities to navigate to different interest of the model and subscribe to that part of discussion. Further, I didn't want to obstruct other documents from being more general or plain presentational; the AWG Design Documents carry more of an intention to disambiguate views, boldy. [[User:Dzonatas Sol|Dzonatas Sol]] 19:11, 23 October 2007 (PDT)

* First, a document template is '''deeply''' not the place to propose a completely new process, especially when there is a page, linked directly off the AWG main page, which discusses process, and is marked tentative, and invites discussion on the topic. Posting such a process, in extreme detail, with none of the material marked as "proposed" or "tentative" or "suggested", but rather having the appearance of a consensus document is frankly hostile to forming consensus.

:Second, having two sets of pages, which in detail, essence and purpose attempt to describe the same basic concepts, is deeply disruptive to collaboration. Having a template document which suggests a flow through the documents which is alternative to the main entry to the wiki, and leads to pages almost entirely duplicative of the main pages, is simply hostile to forming a single perspective.

If you don't agree with a page in the wiki, on a topic, the normal approach is to post a comment on the talk/discuss page for that topic. Please follow this practice. Forking discussion, and forking it in such that it forms a parallel tree is counterproductive.

Lastly, making it harder to edit pages only makes it harder to hold a discussion. I expect to be able to press the edit tab on a wiki page and edit the page. I expect to see a talk/discuss page that's accessible off the page being edited. I do not expect to have to look into templates to find documents which contain meaning, rather than navigation. Please talk to the group, ideally on the talk pages of the wiki, before making major, complex changes to the wiki structure.

[[User:Zha Ewry|Zha Ewry]] 18:08, 24 October 2007 (PDT)

Second Life Grid Glossary

2007-10-24T20:22:11Z

Zha Ewry: /* Agent */ (Tweak mediation)

A glossary of terms with specific meanings within the project, defined so that discussions can be concise and misunderstandings fewer. We also encourage you to take a look at the [[IEEE 1471]] article on designing an effective system architecture which addresses all of the project goals.

Please note that this glossary is specific to the SL Architecture Working Group and is intended for use only within the context of Second Life. The definitions are not expressed in a generic manner, and should not be interpreted that way.

==== Agent ====
'''This is the user portion of the current notion of a SL agent. We may wish to name it '''user agent''' in distinction from the portion of the current notion of a SL agent which remains connected to the user's avatar, which one might call an '''avatar agent''' or "avatar proxy'''

:An Agent is a software resource which represents some portion of a [[Architecture_Working_Group_Glossary#user|user]] in the virtual world. Agents are hosted in agent servers. An agent may cause an avatar to be instantiated on behalf of a user. An Agent mediates, for the user, by acting as the software endpoint in the system which invokes various services within the web at the user's direction, generally via the user's client.

for a tentative example of flows between Clients, Agents and Services, see [[AWG worked agent example]]

:Agents:
:* Mediate the user's message traffic
:* Mediate the user's asset inventory
:* Act as a focal point for the user's access to services in other domains
:* Act as a focal point for the user's access to utilities

:Agents do not:
:* Store persistent assets (They are stored in asset servers)

:Agents are not:
* the portion of the current SL agent which remains in the region simulators

==== Architecture ====
: An abstraction (or mental model) of the SL system which corresponds to its system design. It is revealed through architectural descriptions and multiple views ('''ADV''').
: Alternatively, the end product of a set of processes yielding a set of normative documents which define compliance to the architecture. This is not, inherently in opposition to the first definition as it captures the architecture at different points in its evolution.

==== Architectural descriptions and views (ADV) ====
: Documents which describe (textually and/or graphically) how the various pieces of the SecondLife system fulfil their expected goals. More precisely, ADVs express in detail how the system architecture is conformant with the concerns expressed in viewpoints. Some examples:

: For a ''message flow viewpoint'', ADVs describe how system components interact with one another by describing their relations, protocols and message formats.

: For a ''scalability-oriented viewpoint'', ADVs describe the relevant system resource pools and their capacities, the flow paths and choke points, the bandwidth of links and access mechanisms, the means of expanding capacity, and the analysed scalability of key elements.

: For a ''client capability viewpoint'', ADVs ennumerate and detail the client-related capabilities, client-server capability negociation mechanisms and protocols, means of activating capability negociation, and client-side capability state transitions.

==== Asset ====

: An entity which can be transferred from agent to agent or from agent to region or from region to agent. It can be something like an object, texture, sound, link, landmark, and so forth.
: Architecturally, we destinguish between an '''asset''' and an '''asset reference''':
:* an asset is blog of binary data, some (small) amount of meta data, a URL and a UUID. the meta data contains things like content-type.
:* an asset reference contains a reference to the asset and properties such as permissions. asset references are inventory items.

==== Avatar ====
: The representation of an agent in a region (or somewhere else, like on the web)

==== Component ====
: A logical composition that is proportional to a whole. In the domain architecture of the AWG, these compositions include viewpoints and views. In software and hardware, these include modules, units, and devices.

==== Domain ====
:A partition of architectural resources, and services. A domain can be characterized by its membership and the set of properties that the members share. In Internet usage, a domain is commonly tied to DNS namespace, with the shared property being name resolution. In terms of our architectural structure, domains share a set of properties, and gain some benefit from this distinction.

:The architecture may expose domain membership, and the properties which define the domain through a standard web service.

:Examples of domains might include

:* All the region servers supporting Linden Lab's mainland
:* All the corporate hosted servers supporting XYZ Co's private islands. (Which might include Region, Asset, and Utility serviced specific to XYZ co.)
:* All the servers and services within HostingCorps trusted firewall.

:In each case, the partition permits the members to act differently with respect to each other, than members outside the partition.

:To understand the rationale for this definition, see [[AWG Domain rationale discussion|Domain rationale discussion]].

==== Meta data ====
: Meta data is data ''about'' data: it describes the data and its properties. In the architecture discussions we use ''meta data'' for [[#Asset|assets]].

==== Permissions ====
: A kind of license digest that specifies what rights the creator of an asset grants to a user of that asset (or what rights she doesn't want to grant) [see also [[Protecting content in an open grid]]]

==== Refactored Composition ====
: Refactored Composition refers to a technique to arrange the factors of a composition such that the composition is more orthogonal to a new model. This term, or like terms, is often mistakenly used in expression to just rewrite, remake, or recompose the factors, or lesser constituents, within the same model the composition already exists.

==== Region ====
:Some space. It can have any form. It can be grouped together with other regions. It is part of a region domain.

==== Region Domain ====

:Set of regions sharing one or more properties, permitting them to be grouped into a domain.

:Examples of region domains might include:

:* All of the regions forming a continent run by a service provider
:* All of the regions hosted by the XYZ corporation
:* All of the regions which support a new release of a physics engine

==== Resource ====
* [REST]: software entity, or stored value which can be addressed via a [http://en.wikipedia.org/wiki/Uniform_Resource_Locator URL] One basic design point of the architecture is that it follows RESTful web practices.

* [Scalability]: Any finite architectural component or property or behaviour that is subject to exhaustion or which can become a bottleneck to system performance. Resources are the primary focus in designing for scalability. Examples: client-server bandwidth, agent pool depth, database access mechanism, locks, transaction times, utilities, services.

==== Scalability ====
: The ability of a system to grow effectively ''in a given dimension'' in proportion to the amount of resource or capacity provided. The given dimension is often associated with a related dimension. A specific system may attempt to be ''scaled'' by adding resources, but this is effective only if the system is ''scalable''. Example: scalability in the number of avatars at an event, viewed against the size of the user population, in proportion to the hardware allocated.

==== Service ====
: A Web Services invocable resource which performs some task on behalf of a region

==== Simulation (sim) ====
: A computation over time that mimics real world events within a part of the virtual world.

==== Stakeholder ====
: Anyone who has a ''technical'' viewpoint that impacts on AWG work on system architecture.
: Non-technical viewpoints exist and have validity, but do not fall within the current scope.

==== Use case ====
: A technique used to capture the requirements of a system or architecture. Use cases avoid technical jagon although this often depends on the scope and actors of the use case. Generally, the archtectural terms in this glosary are valid (i.e. Identity, Viewer, Service) while specific technical terms are not (C++, REST, XML). Detail of a AWG use case can vary:

:* A '''brief''' use case consists of a few sentences summarizing the use case.
:* A '''casual''' use case consists of a few paragraphs of text or a [[Early_Stage_Usecase_Template|minimal template]], summarizing the use case.
:* A '''fully dressed''' use case is a formal document based on a detailed template with fields for various sections; and it is the most common understanding of the meaning of a use case.
: For a more general understanding of use cases please see [http://en.wikipedia.org/wiki/Use_case the Wikipedia article].

==== User ====
: An person in control of an agent.

==== Utility ====
: A Service, or collection of services which provides a utility which does not manifest as a region, agent or avatar within the virtual world. Examples: Currency, Identity, Asset Storage, Messaging, Presence, Topology Management.

==== Viewer ====
: Currently, a monolithic client-side program which establishes communication with system servers and displays a visual image of the virtual world. It usually controls an agent represented by an avatar, eventually inside a region. As client programming evolves, the viewer ''per se'' may become only a client subprogram which deals with 3D rendering and UI handling exclusively, assisted by other subprograms.

==== Viewpoint ====
: A set of related concerns about the architecture, and the representations or views used to describe the architecture to address those concerns. Examples: Client viewpoint, Client UI viewpoint, Functional viewpoint, REST Services viewpoint, Scalability viewpoint, Region Scalability viewpoint, Network viewpoint, Manpower viewpoint.

= See Also =

* [[Glossary]]
* [http://pascal.computer.org/sev_display/search.action Software and Systems Engineering Vocabulary]

[[Category:Architecture Working Group]]
[[Category:AWGroupies]]

User:Dzonatas Sol/AWG Design Document Template

2007-10-24T16:49:35Z

Zha Ewry: Replacing page with '{{:AWG/PageHeader}} Process Proposal moved to process talk page, to avoid wiki sprawl, per Wiki:Editing Guidelines https://wiki.secondlife.com/wiki/Talk:AWG_Process'

{{:AWG/PageHeader}}
Process Proposal moved to process talk page, to avoid wiki sprawl, per [[Wiki:Editing Guidelines]]
https://wiki.secondlife.com/wiki/Talk:AWG_Process

AWG Design Document Template/Description

2007-10-24T16:48:43Z

Zha Ewry: Removing all content from page

User talk:Zha Ewry/Proposed AWG Process

2007-10-24T16:47:13Z

Zha Ewry: Pick up Dzon's proposed process ideas

* I think that this accurately describes the process path that AWG seems be travelling at this point. Of special note is that it identifies that the work is being addressed from multiple viewpoints in parallel, and that trial implementations of parts of the system are being made early as this is of special interest to several participants. It looks good to me, a recipe for teamwork.

* The final "code it and test it" is of course just a placeholder, but still funny in its terseness. :-) No doubt we'll expand it more usefully before long, especially in terms of Quality Assurance, elements of which will end up within earlier stages of your process. For example, traceability from viewpoint concerns to elements in the design is an important aspect of QA work, one which the VAGs will be addressing. Likewise, incremental change and regression testing is paramount in a distributed grid where the sun never sets, so we'll have to think about this in the "code it and test it" section in due course. --[[User:Morgaine Dinova|Morgaine Dinova]] 02:01, 18 October 2007 (PDT)

* What? I'm not supposed to have a sense of humor? :-) And... on a slightly less humorous note, it never hurts to keep that final goal in mind. The rest of our points are well taken, and I've tweaked the page to reflect them. -[[User:Zha Ewry| Zha]] 5:33 AM PDT, 18 October 2007

* Until there are resources for the AWG Project in a JIRA domain (hosted by LL or elsewhere), I propose we use several "office hour" style allocations to gather about each subject area or discuss in a geographic-region friendly manner. That way the "groups" as suggested by the VAG proposal can actually show membership by being present at the office hour. That office hour only needs agendas to work on any viewpoint (placed on the agenda) instead of being limit to just the one listed on the current form of VAGs. What we need for these office hours are viewpoints, subjects, participation, the agenda, and the hour the dicussion takes place. Maybe two or three of these are enough for now that'll be friendly to Europe, America, and one other common timezone. [[User:Dzonatas Sol|Dzonatas Sol]] 11:36, 18 October 2007 (PDT)

=== proposed process ideas from Dzonatas Sol ====
[[User:Dzonatas Sol|Dzonatas Sol]]

= How To Use This Template =

* Review [[Design Document Template]] for insight of needed content.

* Design Documents are to describe aspects of the given model. Terminology that is out of scope to describe a specific aspect of the given model belongs in the [[Architecture Working Group Glossary|Glossary]] and does not need its own design document. Rationale: the design documents under this category are specific to the given model. If the title of a design document has the same name of a term that confuses the view, it is best to find a new name for the title of the design document; however, the previous model and the given model both already provide names for aspects of that model, which are commonly used by default for design titles and may confuse the view more if changed. Icons also help to avoid confusion such the icon plus a title can be recognized distinctly from general terminology.

* Title each page with "AWG ''NAMEOFDOC''" where ''NAMEOFDOC'' is the actual name. If possible, upper case only the first letter of each word in ''NAMEOFDOC'', as it is typically done for a title, like "AWG Document Title." The first four characters "AWG " are significant to the macros.

* Start each page with <nowiki>{{:AWG/PageHeader}}</nowiki> in order to transclude the header layout (as shown above) and its macros.

* Avoid generalizations in the Description field. As much as possible, write statements in terms of the now, which means there is an actual model to describe. Also, the use of grammatic infinitives is a bold indication of a generalization (some usage in nouns is unavoidable). Remember, any generalization in design is a bottleneck in implementation.

* Keep the Description field concise but mappable. Use <nowiki>{{AWG|</nowiki>''NAMEOFDOC''<nowiki>}}</nowiki> to map to other AWG design documents. Any specifics beyond basic purpose, terminology, or mappable usage goes in another section (and refer to [[Design Document Template]] for possible sections). The description being mappable to other design documents is a power of the wiki -- use it! (especially to map back to the article itself, for example "A <nowiki>{{AWG|</nowiki>''NAMEOFDOC''<nowiki>}}</nowiki> is ...")

* Upload an icon for the page under the name '''AWG_''NAMEOFDOC''.png''' where ''NAMEOFDOC'' must have underlines instead of spaces. A macro in the pageheader detects the image and inserts it automatically. For now, the icons are sized to 100x100px. Icons are a good means to graphically map the model or indicate states of the model, so it is good to keep them distinct from each other (or redo them to make them more distinct). Don't make icons too complex where it cannot be easily drawn by hand as a conversation piece.

* Use regular wiki sections below the pageheader. For example if there are specifications to list, create a "Specification" section for them.

* Any ''talk'' in the main article is subject to be rewritten to make a formal statement about the design or can be moved to a more appropriate (discussion) page.

= Goals =

* The goal of these AWG Design Documents are to use the abilities of the wiki to create a concise description of interest, with such wikification, in order to express, discuss, and verify a given model being designed. Each article is given workspace for views and viewpoints. The description of interest, being wikified, is navigatible, by its wikicode, to other related design elements. The specifics of each link is tied a each design document in order to augment to consistency of the descriptions with other design documents. Thus, it is possible to verify the given model, and potential any new model, before any implementation because the links avoid generalizations and gives precise directions. Nevertheless, this does not automate the process nor mandates how to write the descriptions, it is provided only to be helpful to both those that design and those that implement the model.

* A secondary goal is to help prevent discussion sprawl. Wikis allow the freedom for discussion to take place on multiple pages, and the intention of the navigational links is to help direct the flow of conversation to the given model. This has already proven to work, but the approach needs refinement to encourage the pull of interest to be less disjoint.

* Also, these design documents provide constructive methods that are useful to visual people, which is positive in accessibility issues.

= Design =

* The guidelines above explain the technique used to make the best of this template. The use of transcluded Description page allows the wikified text (of the description) to be transcluded in other areas of the wiki, which then serves as an informational and navigational instrument.

* '''NOTE:''' If you are familiar with the old MOOs, Zorks, and Adventure style of games, then you will have a perfect example of how the Description should work but with a much more point-n-clickly style of interface instead of keyboarded input to explore! This is comparable to modern S.E.E. tools. (No doubt such environments are based on older Adventure games!)

* [[AWG_Design_Document_Template]], for example, is the main design article and workspace that can be edited more freely, which is where the main discussion should take place.

* [[AWG_Design_Document_Template/Description]], also example, is the transcluded "navigational" Description field, which needs finer structure to ensure a navigational Description functions well with wikilinks to directly related design documents.

* The ability to quickly move into a (standard) '''functional design''' process and '''detailed design phase''' from a general framework or given model is not stated as an explicit goal; do notice the enabled ability to move from a raw conceptual model directly into same standard detailed design process. S.E.E. tools (and MOOs, etc) probably provide a much easier way, likewise, to automatically link/unlink descriptions with each other unlike a wiki, but the wiki provides access to history of changes.

= Interface Requirements =

* Besides the normal use of a wiki and the guidelines above being followed, the user only has to include the wikicode code transclude the description if that is the only text desired from the design document and its workspace. One example of wikicode to include the above description in the header: <nowiki>{{:AWG/AWG_Design_Document_Template}}</nowiki>

= Performance Requirements =

* Specifics of load on the wiki are not known. In general, transcluded pages are updated in the cache as one page, but it still requires extra access to generate the complete page than a single page with no such inclusions. However, the pull of interest is a factor to consider on the span of documents being edited without any helpful navigation. If these templates are found useful, as useful as the wiki itself is as a template, then the growth of articles is expected to be the same, but that is with the assumption a core of documents with these templates are already done to describe the model.

= Security Impact =

* The description of interest becomes more accessible, and its nature to be transcluded allows for one change to make a wider impact. If abused, a request for augmented security might be needed. However, Wikipedia has shown high tolerance before such preventive measures are of need. If a model becomes final and implemented, it may be reasonable to lock the description pages of the that model and start with fresh new design documents for the next model.

= Community Concerns =

* As the design progresses, parts of the model not yet described may appear broken.

= Support =

* Support is limited to the communication channels available. I've found it costly, so far, but I also have learned how to continue to make progress in the design, which is priceless.

= Limitations =

* The in-line DISPLAYTITLE function of the wiki either is not available or not well documented. There is a special:displaytitle page, but there also exists hints of a wiki magic-word that can be inserted in each page in order to make the title display differently from its URL scheme. I have a hint that such feature may not be fully implemented as of yet due to RESTful desires to keep the title and URL scheme very similar. For now, the URL scheme and display title are similar by such limitation.

= Interactions =

* The use of wikicode with HTML works, but wiki users still are in disagreement if HTML is a feature of a wiki. There is HTML in the template in order to use the CSS styles. The transcluded page and the macros of the template have already replaced much HTML code that have been used in the past in like style.

= Testing =

* The approach of these design documents have been a way to test the test. Besides the progressive design and the appearance of being broken when not fully described, it basically passes that test. =) The subsequent test then becomes a need to continue the design and verify the model. The current progress has already found a flaw in the given model in the same way this may appear broken.

= Deployment =

* Besides a fresh start, continue design of the model here with these design documents!

AWG Agent

2007-10-24T16:33:45Z

Zha Ewry: Replacing page with 'Merged into Agent discussion talk, to avoid wiki sprawl, per Editing Guidelines https://wiki.secondlife.com/wiki/Talk:Architecture_Working_Group_Glossary#Agent'

Merged into Agent discussion talk, to avoid wiki sprawl, per [[Editing Guidelines]]
https://wiki.secondlife.com/wiki/Talk:Architecture_Working_Group_Glossary#Agent

Talk:AWG Agent

2007-10-24T16:32:19Z

Zha Ewry: (merged into overall discussion to prevent wiki sprawl)

Merged into the overall discussion on agent, per [[Editing Guidelines]]to prevent wiki sprawl.
https://wiki.secondlife.com/wiki/Talk:Architecture_Working_Group_Glossary#Agent

Talk:Second Life Grid Glossary

2007-10-24T15:21:31Z

Zha Ewry: /* Asset */ (avoid nested page header)

'''Where did the old content go?'''

Don't worry. Its all down below. In order to try and make this a little more focused I am putting in a section in here for each term and section in the glossary. This ''may'' make the page a little more usable. I suppose the next step would be a sub-page per term, but I am resisting that. Feel free to pull still current comments UP into the subsections. I'll try to grab some of that shortly, but. I think authors are probably better suited to that.

==== Agent ====
'''content merged from seperate page to avoid wiki sprawl'''

This is [[User:Dzonatsas Sol]]'s material
= Specifications =

An ''Agent'' is a software resource which represents some portion of a user in the virtual world. Agents are hosted in agent servers. An agent may cause an avatar to be instantiated on behalf of a user.

Agents:

* Mediate the user's message traffic
* Mediate the user's asset inventory
* Act as a focal point for the user's access to services in other domains
* Act as a focal point for the user's access to utilties
* Act to report the user's avatar's location in the Virtual World to other parts of the system

Agents do not:

* Store persistent assets (They are stored in asset servers)

Agents are not:

* The software resource which represents a user's avatar inside a region simulator. (Tho we need a name for that.)

This definition is different from the current (pre agent/region domain split) use of the term agent Second Life. Currently agents are hosted on the simulator where the user's avatar resides, and handle these tasks as well as mediating the avatar's connection to the client. The term agent, in general is overloaded, and is it possible that another, more specific term would be appropriate here.

= Brainstorming =

* The envisaged [[Project_Motivation|massive scaling]] requires new forms of item organization, search, and access to cope with vast expansion. The current inventory mechanism is already stretched right now, so this issue needs early design attention.
* it should be possible to manage inventories of all your agents under one identity. The idea is to e.g. being able to move items from one inventory to another
* some organisation providing agents should be able to define on which regions an agent is allowed to connect, what he/she can do with object in their inventory
* an agent domain should be able to have certain inventory pools which might be shared among agents (like the library in SL today)
* it should be possible to import and export friends lists or groups of friends
* it should be possible to maintain a friends list among various agent domains (related to import/export maybe but as protocol function)
* it should be possible to copy inventory from one agent domain from another if the object structure is compatible.
* an agent needs to provide various methods of verification
* an agent domain needs to define presence information among an agent's friends list. This should even be possible among various agent domains.
* Each agent needs to be able to define certain permissions on what other agents or groups of agents are allowed to see about him (online status, identity information, etc.)

==== possible restrictions between regions and agents ====

* An agent domain should be able to define on which regions an agent is allowed to connect
* An agent domain should be able to define which objects are allowed to be rezzed on which region (e.g. company objects only on company regions etc. This might be related to object pools as described above).
* A region might allow only certain agent domains to connect
* A region might allow anybody to connect but the rights of that agent might be limited depending from where it comes and e.g. which verification mechanism the agent provides.
* Standard specification of rights/permissions in a serialisable form that can be edited by the viewer and uploaded to an authorative per-domain server?

==== Architecture ====

==== Architectural desriptions and views (ADV) ====

==== Asset ====

* (temp note): ''We need some clarity here, and elsewhere in the glossary between a Web Services description of resources such as an asset, and an in use description. If we view all assets as having URLs and a singular place in an asset server where the definitive copy of the asset exists, then we need to separate that from the potentially many places where copies of that set of information may be cached and used.'' -- [[User:Zha Ewry|Zha]]

* Ah.. Actually, if we wish to make a distinction between the asset's data, and its meta-data, then, we have the asset, which would be what we "get" from the URL, and the meta-data, which we seperate from the core item, in one of several ways. There was a nice bit of discussion of this in Zeros office hours on October 18 [[User:Zero Linden/Office Hours/2007 Oct 18|transcript]] -- [[User:Zha Ewry|Zha]] October 18, 2007, 5:42 PDT

* you meant Oct 18, i think. corrected to that effect [[User:Dr Scofield|Dr Scofield]] 03:18, 23 October 2007 (PDT)

* updated the asset entry. question: how does an asset reference come into existence? we need to get the flow for that. [[User:Dr Scofield|Dr Scofield]] 03:18, 23 October 2007 (PDT)

* ''asset is currently under discussion on sldev'' -- [[User:Dr Scofield|Dr Scofield]] 00:19, 18 October 2007 (PDT)
Heart, by your desire, fresh fantasy, deep and pure. You requested that
I tell you the fantasy and how I feel. Not merely a description of it,
but the deepest ways it impacts me. Therefore...

'''Transfered from another page, to ensure we are all on the same page'''

= Abstract Data Structure =

{{AWG|Asset}}:
* {{AWG|Identity}} Property
* Intellectual Property
* Permissive Property
* Metadata

= Specifications =

* Note: The core asset-data is a form of intellectual property; however, one or more assets may allude to one or more combined forms of intellectual property. Another words, the abstractness allows for the one-to-one relation, one-to-many relation, many-to-one relation, and the more implicit many-to-many relation.

* The {{AWG|Agent Store}}s and the {{AWG|Region Store}}s are the primary databases for {{AWG|Asset}}s, which have an {{AWG|Identity}} Property as the primary key, and that key is in a form of a UUID.

* {{AWG|Asset}}s also exist in secondary databases, which perform similar to the primary databases. A cache for {{AWG|Asset}}s is a secondary database.

* The properties and metadata provide the mechanism to access, cache, copy, modify, or distribute the {{AWG|Asset}}s between databases.

* Each {{AWG|Asset}} has only one primary database such that there are never two or more primary databases for a given {{AWG|Asset}}.

* An {{AWG|Asset}} is '''tangible''' if it has a primary database.

* An {{AWG|Asset}} is '''transient''' if it has no primary database. For instance, an {{AWG|Asset}} originates from a secondary database.

* A '''tangible {{AWG|Asset}}''' that alludes to another '''tangible {{AWG|Asset}}''' is '''referential'''.

* A '''transient {{AWG|Asset}}''' that alludes to another {{AWG|Asset}} is '''abstract'''. Note: there a distinct difference between the abstract data type and an abstract {{AWG|Asset}}.

* A '''tangible {{AWG|Asset}}''' that alludes to a '''transient {{AWG|Asset}}''' is '''irrational'''. Note: irrational {{AWG|Asset}}s create complex sanity checks for them to be rationalized if possible.

* An '''{{AWG|Asset}} pointer''' is not an {{AWG|Asset}} itself; it is merely a pointer to an {{AWG|Asset}}. Note: The {{AWG|Asset}} pointer is more implementational than architectural, but we specify it here so that any API design may use it.

= Brainstorming =

* allow objects to only be able to rez on certain regions (adds to the agent's restrictions)
* AND/OR limit object rezzing to specific groups of objects (give region owner ability to control what content is allowed in their regions)
* allow assets to be transferred between agent domains
* allow assets to be accessed from multiple agent domains
* allow truly distributed asset storage
* Think beyond the limitations of prims and sculpties by allowing items made in 3d modelling software to be directly imported onto the grid. Other online virtual 3D environments allow this.
* allow licenses to be attached to objects such as CC licenses etc. Could be some license field in the protocol.
* possibility to add proxies for assets. People running their own servers might want to reduce disk access on the sim machines by adding a second machine with a proxy. Proxies improve response time on webservers with heavy access a lot, so it should work for sims with high traffic, too.
* allow geometry standards to be used for objects. SL doesn't have a tool like Sketchup and so needs to be more open to other existing geometry creation tools (sculpties are too insufficient).
* It is likely that *'''no'''* geometry standards will ''ever'' be sufficient. Therefore, don't waste time on defining geometry standards. Instead, focus on designing a way of making the suite of available geometry standards '''extensible''' simply through ''a posteriori'' addition, without requiring ''a priori'' definition.

* It is possible to implement asset storage in a completely distributed way
** Assets need not be stored in fixed locations (such as in the 'home' grid of the creator, for example)
** A completely Peer-to-Peer (P2P) storage protocol is possible
:: It's worth pointing out that P2P is the ''only'' topology that scales with the number of participants in the world. Other topologies have useful properties and get us part of the way (eg. private distributed authoritative world servers fronted by non-authoritative commercial big-iron caches), but ultimately P2P has no real challanger.
** To be successful it would have to retain many of the properties of the current 'fixed' storage schemes
*** Available: Since the individual physical storage providers in a P2P network can't be trusted, a great deal of redundancy would be required to make it unlikely an asset would ever become unavailable
*** Secure: Assets would need to be encrypted using strong PKI where appropriate (for example, so you can be sure nobody but the primary key holder (/ capability holder) can view your script source or edit your object). For the same reason, no asset should be stored in-whole at any single physical location (hence requiring the collusion of a large number of parties to even assemble the encrypted form of an asset in order to mount a cryptographic attack, unless the 'directory' of storage addresses for the asset has also been compromised). Obviously this wouldn't apply to the 'public' form of an asset (e.g. script bytecode, pre-optimized object mesh etc.).
*** Persistent: Some mechanism to control the lifetime of assets may be needed
**** Given the pace of storage technology progress, it may be possible to just keep every asset ever created (ride the wave of progress)
**** If limited asset lifetimes are needed, some kind of distributed garbage-collection algorithm could be employed
**** What would happen to assets that remain accessible but never 'accessed' for long periods of time? (We don't want the 'virtual data archaeologists' who research the 22nd century in one thousand years from now to keep running into cases of assets that are no longer available just because a long time has passed without 'access'!)
**** Will it be possible to delete assets/accounts someday?
** This may be a hard problem to solve properly now, but just designing an architecture with it in mind and then implementing something similar to the fixed scheme utilized now would leave the possibility open of implementing the more general case in the future.
*** Lets avoid a repeat of the mistake made in the 'design' of the www, where public pages are often stored on servers owned/leased by their creators and routinely lost for the future (save the efforts of the way-back-machine etc).
* Assets should support being signed (and notarized)
** Perhaps they should even allow arbitrary meta-data to be attached to them by their creators (or anyone with perms) and accessed via scripts
* Assets should be raw data.
** Asset type, permissions, creator, watermark, etc would be meta-data.
** Any kind of meta-data could be added and used or ignored as needed.
* How will a region be able to accept an alien object from another system's inventory, or an inventory to accept an object from a foreign region?
** Would an upload fee make sense for transferring objects to different grids? Who will pay it? The creator? The first one who bought it and travels to the other grid?
** If so, how would that fee be determined for a completed object?
** Would some grids (or domains if you'd prefer) be able to reject items from other domains on a permission basis?

=== Decentralized assets ===
* How does a locally-run, disconnected grid provide texture/animation uploads or anything of use without the centralized system to accept the upload fee, read and update the user's inventory, or receive the new asset information?
** Local database backend stores all the local content, any content on the remote asset servers with appropriate permissions (perhaps a "can download" flag?) can be downloaded for use on a local stand-alone grid
** Any new assets, or locally modified assets can be re-uploaded
** "Can download" must imply "Can modify" for practical reasons (DRM will not work!)

''' More material brought onto the common page '''
The identifier for an asset OUTSIDE a specific domain (trust domain, region domain, region, etcetera) is not a UUID, it's a URL. The form of the URL is unspecified, except that the host-part is the address of the asset server responsible for that asset, and that the asset can be manipulated with POST and GET commands passing standard URI-encoded parameters.

Within a domain the identifier of an asset is a UUID that is unique within that dmain and other domains sharing the same trust environment.

Assets hosted in other domains are mapped to UUIDs in a manner that is up to the domain. The expected technique is to create a new instance of the asset, containing a location property with the URI of the original asset, with all other properties copied from theoriginal, and with the asset data possibly cached in the local asset server.

*** -- [[User:Argent Stonecutter|Argent Stonecutter]] 19:11, 23 October 2007 (PDT)

The inside/outside view of the identifier is true for what you say with and without the URL. The technique to create a new instance all depends on if the properties allow. A non-copiable tangible asset may have only a single instance in the entire grid, but there may be several referential assets to allude back to the single non-copiable instance. (See: [[#The Chair]])

*** [[User:Dzonatas Sol|Dzonatas Sol]] 19:31, 23 October 2007 (PDT)

What benefit do you get by using only a UUID inside the domain? It seems like it'd be simpler to just use a unique URL as the identifier all the time. I guess you can save on bytes if the uuid->url translation is trivial, but why bother? That way you don't have to check to see whether the asset is in-domain and thus have to apply the transformation, or out-of-domain and thus do not. Admittedly, debating this point is sort of icing-on-a-tea-crumpet, but, hell, I'd be in favor of moving Second Life's internals to use all urls, all the time.

Also, I do not understand what all this 'alluding' means. Refers to? Contains a url for?

*** [[User:Which Linden|Which Linden]] 22:52, 23 October 2007 (PDT)

Ah, I see where that can get confused about the URL. It is within the Asset's database record that appears bit more of an implementational detail to also store the URL. Given a potential 3rd normal form, one would not store the URL along with the asset unless the URL is part of the IP. I don't totally disagree, but I do question if the identity property of the asset record needs to hold more than a UUID for at least this cycle of the model to design. It still remains abstract enough to allow something other than only a UUID. I've heard hints about the "icing" (I've even suggested similar), and I surely don't want to obstruct the possibility. =)

"Alludes" or an "allusion" is less constrained than being "referred to" (a direct mention), while an allusion is more indirect, like passed by reference. An allusion may evaluate to an object, but the actual reference may be indeterminate by the value of the allusion alone. In implementation (discretely), an object can only make direct reference to other objects, but the structure of the references creates the allusion. For example, an oxygen atom and two hydrogen atoms can directly link to each other, but that linked structure alludes to a discrete molecule. It is too simple of a concept in order for it to be patentable, unlike many popular aspect-oriented languages that can be patented. =)

*** [[User:Dzonatas Sol|Dzonatas Sol]] 07:40, 24 October 2007 (PDT)

= The Chair =

This where the "chair" question came about. What happens if the chair is made up of copiable and non-copiable assets where each piece of the chair being separate intellectual property and each IP owned individually by different people. Let's say the chair was manufactured by buying the seat separately from the base, and separately from the feet, and separately from the textures, so the chair then was assembled together by a person who bought all those pieces from different people. The assembled chair then is set to sell. How does one buy it? What are the steps to perform this? How does each step look in the databases for where each asset exists?

*** [[User:Dzonatas Sol|Dzonatas Sol]] 19:31, 23 October 2007 (PDT)

= Primary Database Thoughts =

* In a decentralized system, there is always the potential net splits to occur. Methods need to be developed to prevent irrational assets or even broken referential assets. For example, one could require the complete form of an intellectual property be stored all in a single primary database with all related assets that constitute that form instead of being allowed to exist in multiple primary databases. [[User:Dzonatas Sol|Dzonatas Sol]] 23:07, 22 October 2007 (PDT)

* It is obvious that movement of tangible assets from one primary database to another primary database needs a cHTTP basis to communicate the move. [[User:Dzonatas Sol|Dzonatas Sol]] 23:07, 22 October 2007 (PDT)

* One way to avoid irrational assets is to allow secondary database be local to a primary database such that the secondary database stores abstract assets instead of the attempt to create irrational assets. I've done a similar scheme like this before on a very small scale, and I already know it is test cases with abstract assets are not as simple as to allow irrational assets. There are, however, less redundant sanity checks are needed with abstract assets locally to the primary database, and it reduces a load on the primary database with assets that would become tangible but actually remain transient. [[User:Dzonatas Sol|Dzonatas Sol]] 23:07, 22 October 2007 (PDT)

== Domains ==

A domain is a group of hosts that may contain assets or instances of assets that share a trust model. They may be a trust domain (the largest contiguous set of hsost sharing a trust model), a region domain (from the original Linden documents), a single server. A uniform domain is one that shares a closer relationship than the AWG model specifies... the Linden grid is a homogenous domain. A non-uniform domain is one in which the AWG model must be used for interoperation between at least some members.

Within a uniform domain, assets are normally referred to using UUIDs.

Between uniform domains, assets are referred to using URLs. THe host part of the URL is the DNS address of the host responsible for that asset (eg, a region or an asset server). The path is unspecified, it merely has to be unique. URI-encoded attributes may be appended to request particular properties, iterate over properties, and (through POST operations) update properties. A standard URI for creating a new asset must be available on any asset host.

An asset may have multiple instances. Each instance contains a COPY of the asset properties that the requestor is allowed to have, a reference (location property) to the original asset, and possibly a cached copy of the asset data. When an instance is created from another instance, the location property of the original asset may be retained in the new instance, or the second instance may become a new independant copy of the asset with a permanent local copy of the asset data... that is, the distinction between instances and assets is flexible.

Details of enforcing intellectual property rights are primarily of interest for groups implementing non-uniform trust domains. Permissions and other rights metadata are only informational between trust domains. This is not to say that IP law does not apply, but that trust domains implementing different trust models can not be compelled to implement all trust models. It is anticipated that most domains will implement an asset property indicating that the asset is not to be transferred into another trust domain.

*** - original content above from article space

This is good information. I like to see how this can be worked into other design documents such as {{AWG|Region Domain}}, {{AWG|Agent Domain}}, and even the components of those domains, like {{AWG|Region Store}}s or {{AWG|Agent Store}}s.

*** [[User:Dzonatas Sol|Dzonatas Sol]] 19:39, 23 October 2007 (PDT)

==== Avatar ====
Does the Avatar represent and agent, or a user? I think a user. The agent is a software construct which permits the user to interact with other portions of the system.

==== Component ====

==== Domain ====
* I replaced the label of the link to "AWG Domain rationale discussion" by "Domain rationale discussion". The use of "AWG Domain" creates terrible confusion and also conflicts with LL's use of the term. The page itself should be renamed too, but that's better done by its creator. --[[User:Morgaine Dinova|Morgaine Dinova]] 09:49, 20 October 2007 (PDT)

* The architecture proposed by LL also created a point of confusion in its use of "Organization Domains" ... there's some sort of dimensional incompatibility there with the use of "Domain" in "Agent Domain" and "Region Domain". [[Talk:Multiple_Domains|I wrote a little about this topic]] back in September when I looked at the diagrams from the first meeting. Organization is better thought of as an attribute within this architecture, because it is so orthogonal to the other domains. What's more, it's a composite attribute with many aspects: for example, a server could belong to company A, provide resources for the group B, and be located in colo C. Which is the Organization domain? There is no single answer. "Organization Domain" isn't a very cohesive concept. --[[User:Morgaine Dinova|Morgaine Dinova]] 10:11, 20 October 2007 (PDT)

==== Meta Data ====

==== Permissions ====

==== Region ====

==== Region Domain ====

==== Resource ====

==== Scalability ====

==== Service ====

==== Simulation (sim) ====

==== Stakeholder ====

==== Use Case ====

==== User ====

==== Utility ====

==== Viewer ====

==== Viewpoint ====

==== See Also ====

==== Pre 10-19-2007 content ====

* The title needs changing to something less specific, like "Glossary", because '''Viewer''' is certainly not a component of a grid. --[[User:Morgaine Dinova|Morgaine Dinova]] 09:29, 25 September 2007 (PDT)

* Added Services and Utilities to the list -- [[User: Zha Ewry|Zha Ewry]] 9/26/2007

* I didn't want to define these since they reference the Linden "implementation" but it would be good to define what is meant by "Central Utilities" and Identity, location, and currency.--[[User:Burhop Piccard|Burhop Piccard]] 17:55, 3 October 2007 (PDT)

* '''Page renaming'''
: As has been discussed on various occasions in AWGroupies and elsewhere, the parent page '''Components and Roles''' has evolved, and as a result it is no longer named appropriately. I would change it to one of the names that have been suggested (eg. AWG_Glossary) if I knew how to migrate its namespace tree as a unit, ie. including Talk, history etc, but I don't know how to do that. Anyone? --[[User:Morgaine Dinova|Morgaine Dinova]] 02:32, 12 October 2007 (PDT)

* did that. refactored page into [[IEEE 1471]] page and glossary page while i was at it. [[User:Dr Scofield|Dr Scofield]] 09:12, 12 October 2007 (PDT)
::* Thanks, that's hugely better. :-) --[[User:Morgaine Dinova|Morgaine Dinova]] 03:57, 13 October 2007 (PDT)

* Reformatted page to use small '====' section headings instead of labels, so that we can edit them one at a time, more scalable. :P --[[User:Morgaine Dinova|Morgaine Dinova]] 03:57, 13 October 2007 (PDT)

* DrS, I've reexpressed your additions under "Architecture" as '''architectural descriptions''' for some randomly-named "''message flow viewpoint''" (maybe it should refer to ''protocols'' or whatever, change as required). The terms for "documents" are in flux --- '''ADV''' for "''architectural descriptions and views''" is just a placeholder, although it seems to work well. Zero has already delivered those nice graphic '''ADV'''s that cover 2 or 3 different viewpoints, although the concerns aren't all that easy to identify in them precisely because they're all thrown in together.
:: The central idea (as in IEEE-1471, which is a synthesis of a billion approaches prevalent in industry), is that "'''The Architecture'''" doesn't in fact exist outside of our heads, and is only communicated in specialised views which reflect the concerns and bias of specific parties.

:: I am forced to admit that I find the bullet point above, simply, at some level incomprehensible. The architecture we are defining is not some platonic ideal. It is a set of formal, normative specifications which to the best of our human capacities specify precisely and unambiguously how to build a conformant implementation. The specifications, hold no viewpoint, they have no biases. They may result from the fusion of many viewpoints, the clash and resolution of many stakeholders, but the architecture is deeply and fundamentally the normative documents which define it and '''nothing else.''' Reifications and realizations of the architecture may deviate from the specifications, but that doesn't change the architecture at all. - [[User:Zha Ewry|Zha]]
::* That's not how the industry sees it Zha. The viewpoint-based approach of IEEE-1471 isn't something radical and new, it's just a distillation (and a very simple non-prescriptive one) of many standard approaches to defining architecture in use throughout computing. Even Zero has effectively used this method in his architectural diagrams, which express the architecture from 2 or 3 different viewpoints. There is actually no other way, no matter how hard you try: your document will always end up describing how the architecture addresses the concerns of a given viewpoint. If you claim that your "normative documents" cover everything salient in the architecture, then all you've done is put all those viewpoint-based descriptions together in one lump. You're not really disagreeing. :-) --[[User:Morgaine Dinova|Morgaine Dinova]] 00:32, 14 October 2007 (PDT)
:::* More importantly though, it allows us all to work separately/grouped but towards a common goal, instead of bickering about what should appear on a one single central document. And an added benefit: it can make it easier for LL to back-port ideas into SL1, since the concerns and solutions will be nicely factored out. Evolution is an important goal, as Zero has made clear. --[[User:Morgaine Dinova|Morgaine Dinova]] 00:41, 14 October 2007 (PDT)

* I added a use case defintion as used with AWG. A "use case" is a bit different since its not really part of the architecture but one of several tools for coming up with an architecture. I still think it goes here because I've tried to narrow the definition a little bit to the AWG context and avoid some of the common misuses of the term. --[[User:Burhop Piccard|Burhop Piccard]] 15:17, 15 October 2007 (PDT)
::* Very useful, as we bandy this term around a lot. :-) It begs for a definition of "user" now, and I can't find a useful one. --[[User:Morgaine Dinova|Morgaine Dinova]] 21:28, 15 October 2007 (PDT)
::* I removed the first external link, to Wikipedia, as it widened the possible meanings rather than narrowing them. The whole point of this AWG glossary is to make us all speak the same language, as the Tower of Babel effect was leading to some unnecessary arguments. External links act in the opposite direction in this case. I left in your second Wikipedia reference, but I don't think that that line helps at all, as it just says "throw in the kitchen sink". If you could revise the line to not need the link, that would be helpful. :-) Perhaps follow the form you set in [[Early_Stage_Usecase_Template|minimal template]] and add a [[Final_Stage_Usecase_Template|detailed template]]? --[[User:Morgaine Dinova|Morgaine Dinova]] 21:58, 15 October 2007 (PDT)

::: Yes, I'd like to create a final state template but its a bit trickier as it needs to be more tailored to the system. I don't think the link is really needed except as a reference for people wanting more information. I'll try to reword it. --[[User:Burhop Piccard|Burhop Piccard]] 09:35, 17 October 2007 (PDT)

* Zha, excellent addition to architecture: you've reconciled the differences through "point in time". Works for me. :-) --[[User:Morgaine Dinova|Morgaine Dinova]] 21:28, 15 October 2007 (PDT)

* I added the "domain" term but I don't think its quite right. Can someone with a better understanding update it? --[[User:Burhop Piccard|Burhop Piccard]] 11:09, 16 October 2007 (PDT)

* In general, skimming the glossary, it feels like we need to get a little more disciplined about how we toss around phrases. For example, "meta data" is defined in a way that only refers to meta data on assets. There are other places in the architecture where we might well want to talk about meta-data, and in fact, depending on exactly how we define and use asset, the meta-data, may or may not always be attached to the asset. Other examples which concern me are resource, where we provide an extremely scalabality centric perspective on resource, which, for example, ignores the common web notion of a resource. We describe, Identity as both an utility and a component. We describe one specific domain, and describe it, in fact in a way which contradicts Zero's diagram, which has two seperate regions domains, both operated by Linden Labs.
I can just go in and start hacking on these, but, I'm hoping the people who posted them will take a careful look at them first. -[[User:Zha Ewry|Zha]] 7:59 pm PDT, October 17, 2007

AWG Agent

2007-10-24T15:20:05Z

Zha Ewry: Merge content to dicussion page to prevent wiki sprawl

content moved to common asset page to prevent wiki sprawl. Per [[Editing Guidelines]]
[https://wiki.secondlife.com/wiki/Talk:Architecture_Working_Group_Glossary#Agent Agent Discussion]]

Talk:Second Life Grid Glossary

2007-10-24T15:18:49Z

Zha Ewry: /* Agent */

'''Where did the old content go?'''

Don't worry. Its all down below. In order to try and make this a little more focused I am putting in a section in here for each term and section in the glossary. This ''may'' make the page a little more usable. I suppose the next step would be a sub-page per term, but I am resisting that. Feel free to pull still current comments UP into the subsections. I'll try to grab some of that shortly, but. I think authors are probably better suited to that.

==== Agent ====
'''content merged from seperate page to avoid wiki sprawl'''

This is [[User:Dzonatsas Sol]]'s material
= Specifications =

An ''Agent'' is a software resource which represents some portion of a user in the virtual world. Agents are hosted in agent servers. An agent may cause an avatar to be instantiated on behalf of a user.

Agents:

* Mediate the user's message traffic
* Mediate the user's asset inventory
* Act as a focal point for the user's access to services in other domains
* Act as a focal point for the user's access to utilties
* Act to report the user's avatar's location in the Virtual World to other parts of the system

Agents do not:

* Store persistent assets (They are stored in asset servers)

Agents are not:

* The software resource which represents a user's avatar inside a region simulator. (Tho we need a name for that.)

This definition is different from the current (pre agent/region domain split) use of the term agent Second Life. Currently agents are hosted on the simulator where the user's avatar resides, and handle these tasks as well as mediating the avatar's connection to the client. The term agent, in general is overloaded, and is it possible that another, more specific term would be appropriate here.

= Brainstorming =

* The envisaged [[Project_Motivation|massive scaling]] requires new forms of item organization, search, and access to cope with vast expansion. The current inventory mechanism is already stretched right now, so this issue needs early design attention.
* it should be possible to manage inventories of all your agents under one identity. The idea is to e.g. being able to move items from one inventory to another
* some organisation providing agents should be able to define on which regions an agent is allowed to connect, what he/she can do with object in their inventory
* an agent domain should be able to have certain inventory pools which might be shared among agents (like the library in SL today)
* it should be possible to import and export friends lists or groups of friends
* it should be possible to maintain a friends list among various agent domains (related to import/export maybe but as protocol function)
* it should be possible to copy inventory from one agent domain from another if the object structure is compatible.
* an agent needs to provide various methods of verification
* an agent domain needs to define presence information among an agent's friends list. This should even be possible among various agent domains.
* Each agent needs to be able to define certain permissions on what other agents or groups of agents are allowed to see about him (online status, identity information, etc.)

==== possible restrictions between regions and agents ====

* An agent domain should be able to define on which regions an agent is allowed to connect
* An agent domain should be able to define which objects are allowed to be rezzed on which region (e.g. company objects only on company regions etc. This might be related to object pools as described above).
* A region might allow only certain agent domains to connect
* A region might allow anybody to connect but the rights of that agent might be limited depending from where it comes and e.g. which verification mechanism the agent provides.
* Standard specification of rights/permissions in a serialisable form that can be edited by the viewer and uploaded to an authorative per-domain server?

==== Architecture ====

==== Architectural desriptions and views (ADV) ====

==== Asset ====

* (temp note): ''We need some clarity here, and elsewhere in the glossary between a Web Services description of resources such as an asset, and an in use description. If we view all assets as having URLs and a singular place in an asset server where the definitive copy of the asset exists, then we need to separate that from the potentially many places where copies of that set of information may be cached and used.'' -- [[User:Zha Ewry|Zha]]

* Ah.. Actually, if we wish to make a distinction between the asset's data, and its meta-data, then, we have the asset, which would be what we "get" from the URL, and the meta-data, which we seperate from the core item, in one of several ways. There was a nice bit of discussion of this in Zeros office hours on October 18 [[User:Zero Linden/Office Hours/2007 Oct 18|transcript]] -- [[User:Zha Ewry|Zha]] October 18, 2007, 5:42 PDT

* you meant Oct 18, i think. corrected to that effect [[User:Dr Scofield|Dr Scofield]] 03:18, 23 October 2007 (PDT)

* updated the asset entry. question: how does an asset reference come into existence? we need to get the flow for that. [[User:Dr Scofield|Dr Scofield]] 03:18, 23 October 2007 (PDT)

* ''asset is currently under discussion on sldev'' -- [[User:Dr Scofield|Dr Scofield]] 00:19, 18 October 2007 (PDT)
Heart, by your desire, fresh fantasy, deep and pure. You requested that
I tell you the fantasy and how I feel. Not merely a description of it,
but the deepest ways it impacts me. Therefore...

'''Transfered from another page, to ensure we are all on the same page'''
{{:AWG/PageHeader}}

= Abstract Data Structure =

{{AWG|Asset}}:
* {{AWG|Identity}} Property
* Intellectual Property
* Permissive Property
* Metadata

= Specifications =

* Note: The core asset-data is a form of intellectual property; however, one or more assets may allude to one or more combined forms of intellectual property. Another words, the abstractness allows for the one-to-one relation, one-to-many relation, many-to-one relation, and the more implicit many-to-many relation.

* The {{AWG|Agent Store}}s and the {{AWG|Region Store}}s are the primary databases for {{AWG|Asset}}s, which have an {{AWG|Identity}} Property as the primary key, and that key is in a form of a UUID.

* {{AWG|Asset}}s also exist in secondary databases, which perform similar to the primary databases. A cache for {{AWG|Asset}}s is a secondary database.

* The properties and metadata provide the mechanism to access, cache, copy, modify, or distribute the {{AWG|Asset}}s between databases.

* Each {{AWG|Asset}} has only one primary database such that there are never two or more primary databases for a given {{AWG|Asset}}.

* An {{AWG|Asset}} is '''tangible''' if it has a primary database.

* An {{AWG|Asset}} is '''transient''' if it has no primary database. For instance, an {{AWG|Asset}} originates from a secondary database.

* A '''tangible {{AWG|Asset}}''' that alludes to another '''tangible {{AWG|Asset}}''' is '''referential'''.

* A '''transient {{AWG|Asset}}''' that alludes to another {{AWG|Asset}} is '''abstract'''. Note: there a distinct difference between the abstract data type and an abstract {{AWG|Asset}}.

* A '''tangible {{AWG|Asset}}''' that alludes to a '''transient {{AWG|Asset}}''' is '''irrational'''. Note: irrational {{AWG|Asset}}s create complex sanity checks for them to be rationalized if possible.

* An '''{{AWG|Asset}} pointer''' is not an {{AWG|Asset}} itself; it is merely a pointer to an {{AWG|Asset}}. Note: The {{AWG|Asset}} pointer is more implementational than architectural, but we specify it here so that any API design may use it.

= Brainstorming =

* allow objects to only be able to rez on certain regions (adds to the agent's restrictions)
* AND/OR limit object rezzing to specific groups of objects (give region owner ability to control what content is allowed in their regions)
* allow assets to be transferred between agent domains
* allow assets to be accessed from multiple agent domains
* allow truly distributed asset storage
* Think beyond the limitations of prims and sculpties by allowing items made in 3d modelling software to be directly imported onto the grid. Other online virtual 3D environments allow this.
* allow licenses to be attached to objects such as CC licenses etc. Could be some license field in the protocol.
* possibility to add proxies for assets. People running their own servers might want to reduce disk access on the sim machines by adding a second machine with a proxy. Proxies improve response time on webservers with heavy access a lot, so it should work for sims with high traffic, too.
* allow geometry standards to be used for objects. SL doesn't have a tool like Sketchup and so needs to be more open to other existing geometry creation tools (sculpties are too insufficient).
* It is likely that *'''no'''* geometry standards will ''ever'' be sufficient. Therefore, don't waste time on defining geometry standards. Instead, focus on designing a way of making the suite of available geometry standards '''extensible''' simply through ''a posteriori'' addition, without requiring ''a priori'' definition.

* It is possible to implement asset storage in a completely distributed way
** Assets need not be stored in fixed locations (such as in the 'home' grid of the creator, for example)
** A completely Peer-to-Peer (P2P) storage protocol is possible
:: It's worth pointing out that P2P is the ''only'' topology that scales with the number of participants in the world. Other topologies have useful properties and get us part of the way (eg. private distributed authoritative world servers fronted by non-authoritative commercial big-iron caches), but ultimately P2P has no real challanger.
** To be successful it would have to retain many of the properties of the current 'fixed' storage schemes
*** Available: Since the individual physical storage providers in a P2P network can't be trusted, a great deal of redundancy would be required to make it unlikely an asset would ever become unavailable
*** Secure: Assets would need to be encrypted using strong PKI where appropriate (for example, so you can be sure nobody but the primary key holder (/ capability holder) can view your script source or edit your object). For the same reason, no asset should be stored in-whole at any single physical location (hence requiring the collusion of a large number of parties to even assemble the encrypted form of an asset in order to mount a cryptographic attack, unless the 'directory' of storage addresses for the asset has also been compromised). Obviously this wouldn't apply to the 'public' form of an asset (e.g. script bytecode, pre-optimized object mesh etc.).
*** Persistent: Some mechanism to control the lifetime of assets may be needed
**** Given the pace of storage technology progress, it may be possible to just keep every asset ever created (ride the wave of progress)
**** If limited asset lifetimes are needed, some kind of distributed garbage-collection algorithm could be employed
**** What would happen to assets that remain accessible but never 'accessed' for long periods of time? (We don't want the 'virtual data archaeologists' who research the 22nd century in one thousand years from now to keep running into cases of assets that are no longer available just because a long time has passed without 'access'!)
**** Will it be possible to delete assets/accounts someday?
** This may be a hard problem to solve properly now, but just designing an architecture with it in mind and then implementing something similar to the fixed scheme utilized now would leave the possibility open of implementing the more general case in the future.
*** Lets avoid a repeat of the mistake made in the 'design' of the www, where public pages are often stored on servers owned/leased by their creators and routinely lost for the future (save the efforts of the way-back-machine etc).
* Assets should support being signed (and notarized)
** Perhaps they should even allow arbitrary meta-data to be attached to them by their creators (or anyone with perms) and accessed via scripts
* Assets should be raw data.
** Asset type, permissions, creator, watermark, etc would be meta-data.
** Any kind of meta-data could be added and used or ignored as needed.
* How will a region be able to accept an alien object from another system's inventory, or an inventory to accept an object from a foreign region?
** Would an upload fee make sense for transferring objects to different grids? Who will pay it? The creator? The first one who bought it and travels to the other grid?
** If so, how would that fee be determined for a completed object?
** Would some grids (or domains if you'd prefer) be able to reject items from other domains on a permission basis?

=== Decentralized assets ===
* How does a locally-run, disconnected grid provide texture/animation uploads or anything of use without the centralized system to accept the upload fee, read and update the user's inventory, or receive the new asset information?
** Local database backend stores all the local content, any content on the remote asset servers with appropriate permissions (perhaps a "can download" flag?) can be downloaded for use on a local stand-alone grid
** Any new assets, or locally modified assets can be re-uploaded
** "Can download" must imply "Can modify" for practical reasons (DRM will not work!)

''' More material brought onto the common page '''
The identifier for an asset OUTSIDE a specific domain (trust domain, region domain, region, etcetera) is not a UUID, it's a URL. The form of the URL is unspecified, except that the host-part is the address of the asset server responsible for that asset, and that the asset can be manipulated with POST and GET commands passing standard URI-encoded parameters.

Within a domain the identifier of an asset is a UUID that is unique within that dmain and other domains sharing the same trust environment.

Assets hosted in other domains are mapped to UUIDs in a manner that is up to the domain. The expected technique is to create a new instance of the asset, containing a location property with the URI of the original asset, with all other properties copied from theoriginal, and with the asset data possibly cached in the local asset server.

*** -- [[User:Argent Stonecutter|Argent Stonecutter]] 19:11, 23 October 2007 (PDT)

The inside/outside view of the identifier is true for what you say with and without the URL. The technique to create a new instance all depends on if the properties allow. A non-copiable tangible asset may have only a single instance in the entire grid, but there may be several referential assets to allude back to the single non-copiable instance. (See: [[#The Chair]])

*** [[User:Dzonatas Sol|Dzonatas Sol]] 19:31, 23 October 2007 (PDT)

What benefit do you get by using only a UUID inside the domain? It seems like it'd be simpler to just use a unique URL as the identifier all the time. I guess you can save on bytes if the uuid->url translation is trivial, but why bother? That way you don't have to check to see whether the asset is in-domain and thus have to apply the transformation, or out-of-domain and thus do not. Admittedly, debating this point is sort of icing-on-a-tea-crumpet, but, hell, I'd be in favor of moving Second Life's internals to use all urls, all the time.

Also, I do not understand what all this 'alluding' means. Refers to? Contains a url for?

*** [[User:Which Linden|Which Linden]] 22:52, 23 October 2007 (PDT)

Ah, I see where that can get confused about the URL. It is within the Asset's database record that appears bit more of an implementational detail to also store the URL. Given a potential 3rd normal form, one would not store the URL along with the asset unless the URL is part of the IP. I don't totally disagree, but I do question if the identity property of the asset record needs to hold more than a UUID for at least this cycle of the model to design. It still remains abstract enough to allow something other than only a UUID. I've heard hints about the "icing" (I've even suggested similar), and I surely don't want to obstruct the possibility. =)

"Alludes" or an "allusion" is less constrained than being "referred to" (a direct mention), while an allusion is more indirect, like passed by reference. An allusion may evaluate to an object, but the actual reference may be indeterminate by the value of the allusion alone. In implementation (discretely), an object can only make direct reference to other objects, but the structure of the references creates the allusion. For example, an oxygen atom and two hydrogen atoms can directly link to each other, but that linked structure alludes to a discrete molecule. It is too simple of a concept in order for it to be patentable, unlike many popular aspect-oriented languages that can be patented. =)

*** [[User:Dzonatas Sol|Dzonatas Sol]] 07:40, 24 October 2007 (PDT)

= The Chair =

This where the "chair" question came about. What happens if the chair is made up of copiable and non-copiable assets where each piece of the chair being separate intellectual property and each IP owned individually by different people. Let's say the chair was manufactured by buying the seat separately from the base, and separately from the feet, and separately from the textures, so the chair then was assembled together by a person who bought all those pieces from different people. The assembled chair then is set to sell. How does one buy it? What are the steps to perform this? How does each step look in the databases for where each asset exists?

*** [[User:Dzonatas Sol|Dzonatas Sol]] 19:31, 23 October 2007 (PDT)

= Primary Database Thoughts =

* In a decentralized system, there is always the potential net splits to occur. Methods need to be developed to prevent irrational assets or even broken referential assets. For example, one could require the complete form of an intellectual property be stored all in a single primary database with all related assets that constitute that form instead of being allowed to exist in multiple primary databases. [[User:Dzonatas Sol|Dzonatas Sol]] 23:07, 22 October 2007 (PDT)

* It is obvious that movement of tangible assets from one primary database to another primary database needs a cHTTP basis to communicate the move. [[User:Dzonatas Sol|Dzonatas Sol]] 23:07, 22 October 2007 (PDT)

* One way to avoid irrational assets is to allow secondary database be local to a primary database such that the secondary database stores abstract assets instead of the attempt to create irrational assets. I've done a similar scheme like this before on a very small scale, and I already know it is test cases with abstract assets are not as simple as to allow irrational assets. There are, however, less redundant sanity checks are needed with abstract assets locally to the primary database, and it reduces a load on the primary database with assets that would become tangible but actually remain transient. [[User:Dzonatas Sol|Dzonatas Sol]] 23:07, 22 October 2007 (PDT)

== Domains ==

A domain is a group of hosts that may contain assets or instances of assets that share a trust model. They may be a trust domain (the largest contiguous set of hsost sharing a trust model), a region domain (from the original Linden documents), a single server. A uniform domain is one that shares a closer relationship than the AWG model specifies... the Linden grid is a homogenous domain. A non-uniform domain is one in which the AWG model must be used for interoperation between at least some members.

Within a uniform domain, assets are normally referred to using UUIDs.

Between uniform domains, assets are referred to using URLs. THe host part of the URL is the DNS address of the host responsible for that asset (eg, a region or an asset server). The path is unspecified, it merely has to be unique. URI-encoded attributes may be appended to request particular properties, iterate over properties, and (through POST operations) update properties. A standard URI for creating a new asset must be available on any asset host.

An asset may have multiple instances. Each instance contains a COPY of the asset properties that the requestor is allowed to have, a reference (location property) to the original asset, and possibly a cached copy of the asset data. When an instance is created from another instance, the location property of the original asset may be retained in the new instance, or the second instance may become a new independant copy of the asset with a permanent local copy of the asset data... that is, the distinction between instances and assets is flexible.

Details of enforcing intellectual property rights are primarily of interest for groups implementing non-uniform trust domains. Permissions and other rights metadata are only informational between trust domains. This is not to say that IP law does not apply, but that trust domains implementing different trust models can not be compelled to implement all trust models. It is anticipated that most domains will implement an asset property indicating that the asset is not to be transferred into another trust domain.

*** - original content above from article space

This is good information. I like to see how this can be worked into other design documents such as {{AWG|Region Domain}}, {{AWG|Agent Domain}}, and even the components of those domains, like {{AWG|Region Store}}s or {{AWG|Agent Store}}s.

*** [[User:Dzonatas Sol|Dzonatas Sol]] 19:39, 23 October 2007 (PDT)

==== Avatar ====
Does the Avatar represent and agent, or a user? I think a user. The agent is a software construct which permits the user to interact with other portions of the system.

==== Component ====

==== Domain ====
* I replaced the label of the link to "AWG Domain rationale discussion" by "Domain rationale discussion". The use of "AWG Domain" creates terrible confusion and also conflicts with LL's use of the term. The page itself should be renamed too, but that's better done by its creator. --[[User:Morgaine Dinova|Morgaine Dinova]] 09:49, 20 October 2007 (PDT)

* The architecture proposed by LL also created a point of confusion in its use of "Organization Domains" ... there's some sort of dimensional incompatibility there with the use of "Domain" in "Agent Domain" and "Region Domain". [[Talk:Multiple_Domains|I wrote a little about this topic]] back in September when I looked at the diagrams from the first meeting. Organization is better thought of as an attribute within this architecture, because it is so orthogonal to the other domains. What's more, it's a composite attribute with many aspects: for example, a server could belong to company A, provide resources for the group B, and be located in colo C. Which is the Organization domain? There is no single answer. "Organization Domain" isn't a very cohesive concept. --[[User:Morgaine Dinova|Morgaine Dinova]] 10:11, 20 October 2007 (PDT)

==== Meta Data ====

==== Permissions ====

==== Region ====

==== Region Domain ====

==== Resource ====

==== Scalability ====

==== Service ====

==== Simulation (sim) ====

==== Stakeholder ====

==== Use Case ====

==== User ====

==== Utility ====

==== Viewer ====

==== Viewpoint ====

==== See Also ====

==== Pre 10-19-2007 content ====

* The title needs changing to something less specific, like "Glossary", because '''Viewer''' is certainly not a component of a grid. --[[User:Morgaine Dinova|Morgaine Dinova]] 09:29, 25 September 2007 (PDT)

* Added Services and Utilities to the list -- [[User: Zha Ewry|Zha Ewry]] 9/26/2007

* I didn't want to define these since they reference the Linden "implementation" but it would be good to define what is meant by "Central Utilities" and Identity, location, and currency.--[[User:Burhop Piccard|Burhop Piccard]] 17:55, 3 October 2007 (PDT)

* '''Page renaming'''
: As has been discussed on various occasions in AWGroupies and elsewhere, the parent page '''Components and Roles''' has evolved, and as a result it is no longer named appropriately. I would change it to one of the names that have been suggested (eg. AWG_Glossary) if I knew how to migrate its namespace tree as a unit, ie. including Talk, history etc, but I don't know how to do that. Anyone? --[[User:Morgaine Dinova|Morgaine Dinova]] 02:32, 12 October 2007 (PDT)

* did that. refactored page into [[IEEE 1471]] page and glossary page while i was at it. [[User:Dr Scofield|Dr Scofield]] 09:12, 12 October 2007 (PDT)
::* Thanks, that's hugely better. :-) --[[User:Morgaine Dinova|Morgaine Dinova]] 03:57, 13 October 2007 (PDT)

* Reformatted page to use small '====' section headings instead of labels, so that we can edit them one at a time, more scalable. :P --[[User:Morgaine Dinova|Morgaine Dinova]] 03:57, 13 October 2007 (PDT)

* DrS, I've reexpressed your additions under "Architecture" as '''architectural descriptions''' for some randomly-named "''message flow viewpoint''" (maybe it should refer to ''protocols'' or whatever, change as required). The terms for "documents" are in flux --- '''ADV''' for "''architectural descriptions and views''" is just a placeholder, although it seems to work well. Zero has already delivered those nice graphic '''ADV'''s that cover 2 or 3 different viewpoints, although the concerns aren't all that easy to identify in them precisely because they're all thrown in together.
:: The central idea (as in IEEE-1471, which is a synthesis of a billion approaches prevalent in industry), is that "'''The Architecture'''" doesn't in fact exist outside of our heads, and is only communicated in specialised views which reflect the concerns and bias of specific parties.

:: I am forced to admit that I find the bullet point above, simply, at some level incomprehensible. The architecture we are defining is not some platonic ideal. It is a set of formal, normative specifications which to the best of our human capacities specify precisely and unambiguously how to build a conformant implementation. The specifications, hold no viewpoint, they have no biases. They may result from the fusion of many viewpoints, the clash and resolution of many stakeholders, but the architecture is deeply and fundamentally the normative documents which define it and '''nothing else.''' Reifications and realizations of the architecture may deviate from the specifications, but that doesn't change the architecture at all. - [[User:Zha Ewry|Zha]]
::* That's not how the industry sees it Zha. The viewpoint-based approach of IEEE-1471 isn't something radical and new, it's just a distillation (and a very simple non-prescriptive one) of many standard approaches to defining architecture in use throughout computing. Even Zero has effectively used this method in his architectural diagrams, which express the architecture from 2 or 3 different viewpoints. There is actually no other way, no matter how hard you try: your document will always end up describing how the architecture addresses the concerns of a given viewpoint. If you claim that your "normative documents" cover everything salient in the architecture, then all you've done is put all those viewpoint-based descriptions together in one lump. You're not really disagreeing. :-) --[[User:Morgaine Dinova|Morgaine Dinova]] 00:32, 14 October 2007 (PDT)
:::* More importantly though, it allows us all to work separately/grouped but towards a common goal, instead of bickering about what should appear on a one single central document. And an added benefit: it can make it easier for LL to back-port ideas into SL1, since the concerns and solutions will be nicely factored out. Evolution is an important goal, as Zero has made clear. --[[User:Morgaine Dinova|Morgaine Dinova]] 00:41, 14 October 2007 (PDT)

* I added a use case defintion as used with AWG. A "use case" is a bit different since its not really part of the architecture but one of several tools for coming up with an architecture. I still think it goes here because I've tried to narrow the definition a little bit to the AWG context and avoid some of the common misuses of the term. --[[User:Burhop Piccard|Burhop Piccard]] 15:17, 15 October 2007 (PDT)
::* Very useful, as we bandy this term around a lot. :-) It begs for a definition of "user" now, and I can't find a useful one. --[[User:Morgaine Dinova|Morgaine Dinova]] 21:28, 15 October 2007 (PDT)
::* I removed the first external link, to Wikipedia, as it widened the possible meanings rather than narrowing them. The whole point of this AWG glossary is to make us all speak the same language, as the Tower of Babel effect was leading to some unnecessary arguments. External links act in the opposite direction in this case. I left in your second Wikipedia reference, but I don't think that that line helps at all, as it just says "throw in the kitchen sink". If you could revise the line to not need the link, that would be helpful. :-) Perhaps follow the form you set in [[Early_Stage_Usecase_Template|minimal template]] and add a [[Final_Stage_Usecase_Template|detailed template]]? --[[User:Morgaine Dinova|Morgaine Dinova]] 21:58, 15 October 2007 (PDT)

::: Yes, I'd like to create a final state template but its a bit trickier as it needs to be more tailored to the system. I don't think the link is really needed except as a reference for people wanting more information. I'll try to reword it. --[[User:Burhop Piccard|Burhop Piccard]] 09:35, 17 October 2007 (PDT)

* Zha, excellent addition to architecture: you've reconciled the differences through "point in time". Works for me. :-) --[[User:Morgaine Dinova|Morgaine Dinova]] 21:28, 15 October 2007 (PDT)

* I added the "domain" term but I don't think its quite right. Can someone with a better understanding update it? --[[User:Burhop Piccard|Burhop Piccard]] 11:09, 16 October 2007 (PDT)

* In general, skimming the glossary, it feels like we need to get a little more disciplined about how we toss around phrases. For example, "meta data" is defined in a way that only refers to meta data on assets. There are other places in the architecture where we might well want to talk about meta-data, and in fact, depending on exactly how we define and use asset, the meta-data, may or may not always be attached to the asset. Other examples which concern me are resource, where we provide an extremely scalabality centric perspective on resource, which, for example, ignores the common web notion of a resource. We describe, Identity as both an utility and a component. We describe one specific domain, and describe it, in fact in a way which contradicts Zero's diagram, which has two seperate regions domains, both operated by Linden Labs.
I can just go in and start hacking on these, but, I'm hoping the people who posted them will take a careful look at them first. -[[User:Zha Ewry|Zha]] 7:59 pm PDT, October 17, 2007

User:Dzonatas Sol/AWG Asset

2007-10-24T15:13:44Z

Zha Ewry: Merge content with common asset discussion page

Content moved to common asset talk page to prevent wiki sprawl, per [[Editing Guildlines]]
[https://wiki.secondlife.com/wiki/Talk:Architecture_Working_Group_Glossary#Asset Asset discussion page]

User talk:Dzonatas Sol/AWG Asset

2007-10-24T15:12:40Z

Zha Ewry:

Content moved to common asset talk page to prevent wiki sprawl, per [[Editing Guildlines]]
[https://wiki.secondlife.com/wiki/Talk:Architecture_Working_Group_Glossary#Asset Asset discussion page]

User talk:Dzonatas Sol/AWG Asset

2007-10-24T15:06:54Z

Zha Ewry: Keep common topics on one page, prevent wiki sprawl

Content moved to common asset talk page to prevent wiki sprawl, per [[Editing Guildlines]]

Talk:Second Life Grid Glossary

2007-10-24T15:05:27Z

Zha Ewry: /* Asset */ (Captured Thoughs from personal perspective page to share page for consensus building)

'''Where did the old content go?'''

Don't worry. Its all down below. In order to try and make this a little more focused I am putting in a section in here for each term and section in the glossary. This ''may'' make the page a little more usable. I suppose the next step would be a sub-page per term, but I am resisting that. Feel free to pull still current comments UP into the subsections. I'll try to grab some of that shortly, but. I think authors are probably better suited to that.

==== Agent ====

==== Architecture ====

==== Architectural desriptions and views (ADV) ====

==== Asset ====

* (temp note): ''We need some clarity here, and elsewhere in the glossary between a Web Services description of resources such as an asset, and an in use description. If we view all assets as having URLs and a singular place in an asset server where the definitive copy of the asset exists, then we need to separate that from the potentially many places where copies of that set of information may be cached and used.'' -- [[User:Zha Ewry|Zha]]

* Ah.. Actually, if we wish to make a distinction between the asset's data, and its meta-data, then, we have the asset, which would be what we "get" from the URL, and the meta-data, which we seperate from the core item, in one of several ways. There was a nice bit of discussion of this in Zeros office hours on October 18 [[User:Zero Linden/Office Hours/2007 Oct 18|transcript]] -- [[User:Zha Ewry|Zha]] October 18, 2007, 5:42 PDT

* you meant Oct 18, i think. corrected to that effect [[User:Dr Scofield|Dr Scofield]] 03:18, 23 October 2007 (PDT)

* updated the asset entry. question: how does an asset reference come into existence? we need to get the flow for that. [[User:Dr Scofield|Dr Scofield]] 03:18, 23 October 2007 (PDT)

* ''asset is currently under discussion on sldev'' -- [[User:Dr Scofield|Dr Scofield]] 00:19, 18 October 2007 (PDT)
Heart, by your desire, fresh fantasy, deep and pure. You requested that
I tell you the fantasy and how I feel. Not merely a description of it,
but the deepest ways it impacts me. Therefore...

'''Transfered from another page, to ensure we are all on the same page'''
{{:AWG/PageHeader}}

= Abstract Data Structure =

{{AWG|Asset}}:
* {{AWG|Identity}} Property
* Intellectual Property
* Permissive Property
* Metadata

= Specifications =

* Note: The core asset-data is a form of intellectual property; however, one or more assets may allude to one or more combined forms of intellectual property. Another words, the abstractness allows for the one-to-one relation, one-to-many relation, many-to-one relation, and the more implicit many-to-many relation.

* The {{AWG|Agent Store}}s and the {{AWG|Region Store}}s are the primary databases for {{AWG|Asset}}s, which have an {{AWG|Identity}} Property as the primary key, and that key is in a form of a UUID.

* {{AWG|Asset}}s also exist in secondary databases, which perform similar to the primary databases. A cache for {{AWG|Asset}}s is a secondary database.

* The properties and metadata provide the mechanism to access, cache, copy, modify, or distribute the {{AWG|Asset}}s between databases.

* Each {{AWG|Asset}} has only one primary database such that there are never two or more primary databases for a given {{AWG|Asset}}.

* An {{AWG|Asset}} is '''tangible''' if it has a primary database.

* An {{AWG|Asset}} is '''transient''' if it has no primary database. For instance, an {{AWG|Asset}} originates from a secondary database.

* A '''tangible {{AWG|Asset}}''' that alludes to another '''tangible {{AWG|Asset}}''' is '''referential'''.

* A '''transient {{AWG|Asset}}''' that alludes to another {{AWG|Asset}} is '''abstract'''. Note: there a distinct difference between the abstract data type and an abstract {{AWG|Asset}}.

* A '''tangible {{AWG|Asset}}''' that alludes to a '''transient {{AWG|Asset}}''' is '''irrational'''. Note: irrational {{AWG|Asset}}s create complex sanity checks for them to be rationalized if possible.

* An '''{{AWG|Asset}} pointer''' is not an {{AWG|Asset}} itself; it is merely a pointer to an {{AWG|Asset}}. Note: The {{AWG|Asset}} pointer is more implementational than architectural, but we specify it here so that any API design may use it.

= Brainstorming =

* allow objects to only be able to rez on certain regions (adds to the agent's restrictions)
* AND/OR limit object rezzing to specific groups of objects (give region owner ability to control what content is allowed in their regions)
* allow assets to be transferred between agent domains
* allow assets to be accessed from multiple agent domains
* allow truly distributed asset storage
* Think beyond the limitations of prims and sculpties by allowing items made in 3d modelling software to be directly imported onto the grid. Other online virtual 3D environments allow this.
* allow licenses to be attached to objects such as CC licenses etc. Could be some license field in the protocol.
* possibility to add proxies for assets. People running their own servers might want to reduce disk access on the sim machines by adding a second machine with a proxy. Proxies improve response time on webservers with heavy access a lot, so it should work for sims with high traffic, too.
* allow geometry standards to be used for objects. SL doesn't have a tool like Sketchup and so needs to be more open to other existing geometry creation tools (sculpties are too insufficient).
* It is likely that *'''no'''* geometry standards will ''ever'' be sufficient. Therefore, don't waste time on defining geometry standards. Instead, focus on designing a way of making the suite of available geometry standards '''extensible''' simply through ''a posteriori'' addition, without requiring ''a priori'' definition.

* It is possible to implement asset storage in a completely distributed way
** Assets need not be stored in fixed locations (such as in the 'home' grid of the creator, for example)
** A completely Peer-to-Peer (P2P) storage protocol is possible
:: It's worth pointing out that P2P is the ''only'' topology that scales with the number of participants in the world. Other topologies have useful properties and get us part of the way (eg. private distributed authoritative world servers fronted by non-authoritative commercial big-iron caches), but ultimately P2P has no real challanger.
** To be successful it would have to retain many of the properties of the current 'fixed' storage schemes
*** Available: Since the individual physical storage providers in a P2P network can't be trusted, a great deal of redundancy would be required to make it unlikely an asset would ever become unavailable
*** Secure: Assets would need to be encrypted using strong PKI where appropriate (for example, so you can be sure nobody but the primary key holder (/ capability holder) can view your script source or edit your object). For the same reason, no asset should be stored in-whole at any single physical location (hence requiring the collusion of a large number of parties to even assemble the encrypted form of an asset in order to mount a cryptographic attack, unless the 'directory' of storage addresses for the asset has also been compromised). Obviously this wouldn't apply to the 'public' form of an asset (e.g. script bytecode, pre-optimized object mesh etc.).
*** Persistent: Some mechanism to control the lifetime of assets may be needed
**** Given the pace of storage technology progress, it may be possible to just keep every asset ever created (ride the wave of progress)
**** If limited asset lifetimes are needed, some kind of distributed garbage-collection algorithm could be employed
**** What would happen to assets that remain accessible but never 'accessed' for long periods of time? (We don't want the 'virtual data archaeologists' who research the 22nd century in one thousand years from now to keep running into cases of assets that are no longer available just because a long time has passed without 'access'!)
**** Will it be possible to delete assets/accounts someday?
** This may be a hard problem to solve properly now, but just designing an architecture with it in mind and then implementing something similar to the fixed scheme utilized now would leave the possibility open of implementing the more general case in the future.
*** Lets avoid a repeat of the mistake made in the 'design' of the www, where public pages are often stored on servers owned/leased by their creators and routinely lost for the future (save the efforts of the way-back-machine etc).
* Assets should support being signed (and notarized)
** Perhaps they should even allow arbitrary meta-data to be attached to them by their creators (or anyone with perms) and accessed via scripts
* Assets should be raw data.
** Asset type, permissions, creator, watermark, etc would be meta-data.
** Any kind of meta-data could be added and used or ignored as needed.
* How will a region be able to accept an alien object from another system's inventory, or an inventory to accept an object from a foreign region?
** Would an upload fee make sense for transferring objects to different grids? Who will pay it? The creator? The first one who bought it and travels to the other grid?
** If so, how would that fee be determined for a completed object?
** Would some grids (or domains if you'd prefer) be able to reject items from other domains on a permission basis?

=== Decentralized assets ===
* How does a locally-run, disconnected grid provide texture/animation uploads or anything of use without the centralized system to accept the upload fee, read and update the user's inventory, or receive the new asset information?
** Local database backend stores all the local content, any content on the remote asset servers with appropriate permissions (perhaps a "can download" flag?) can be downloaded for use on a local stand-alone grid
** Any new assets, or locally modified assets can be re-uploaded
** "Can download" must imply "Can modify" for practical reasons (DRM will not work!)

''' More material brought onto the common page '''
The identifier for an asset OUTSIDE a specific domain (trust domain, region domain, region, etcetera) is not a UUID, it's a URL. The form of the URL is unspecified, except that the host-part is the address of the asset server responsible for that asset, and that the asset can be manipulated with POST and GET commands passing standard URI-encoded parameters.

Within a domain the identifier of an asset is a UUID that is unique within that dmain and other domains sharing the same trust environment.

Assets hosted in other domains are mapped to UUIDs in a manner that is up to the domain. The expected technique is to create a new instance of the asset, containing a location property with the URI of the original asset, with all other properties copied from theoriginal, and with the asset data possibly cached in the local asset server.

*** -- [[User:Argent Stonecutter|Argent Stonecutter]] 19:11, 23 October 2007 (PDT)

The inside/outside view of the identifier is true for what you say with and without the URL. The technique to create a new instance all depends on if the properties allow. A non-copiable tangible asset may have only a single instance in the entire grid, but there may be several referential assets to allude back to the single non-copiable instance. (See: [[#The Chair]])

*** [[User:Dzonatas Sol|Dzonatas Sol]] 19:31, 23 October 2007 (PDT)

What benefit do you get by using only a UUID inside the domain? It seems like it'd be simpler to just use a unique URL as the identifier all the time. I guess you can save on bytes if the uuid->url translation is trivial, but why bother? That way you don't have to check to see whether the asset is in-domain and thus have to apply the transformation, or out-of-domain and thus do not. Admittedly, debating this point is sort of icing-on-a-tea-crumpet, but, hell, I'd be in favor of moving Second Life's internals to use all urls, all the time.

Also, I do not understand what all this 'alluding' means. Refers to? Contains a url for?

*** [[User:Which Linden|Which Linden]] 22:52, 23 October 2007 (PDT)

Ah, I see where that can get confused about the URL. It is within the Asset's database record that appears bit more of an implementational detail to also store the URL. Given a potential 3rd normal form, one would not store the URL along with the asset unless the URL is part of the IP. I don't totally disagree, but I do question if the identity property of the asset record needs to hold more than a UUID for at least this cycle of the model to design. It still remains abstract enough to allow something other than only a UUID. I've heard hints about the "icing" (I've even suggested similar), and I surely don't want to obstruct the possibility. =)

"Alludes" or an "allusion" is less constrained than being "referred to" (a direct mention), while an allusion is more indirect, like passed by reference. An allusion may evaluate to an object, but the actual reference may be indeterminate by the value of the allusion alone. In implementation (discretely), an object can only make direct reference to other objects, but the structure of the references creates the allusion. For example, an oxygen atom and two hydrogen atoms can directly link to each other, but that linked structure alludes to a discrete molecule. It is too simple of a concept in order for it to be patentable, unlike many popular aspect-oriented languages that can be patented. =)

*** [[User:Dzonatas Sol|Dzonatas Sol]] 07:40, 24 October 2007 (PDT)

= The Chair =

This where the "chair" question came about. What happens if the chair is made up of copiable and non-copiable assets where each piece of the chair being separate intellectual property and each IP owned individually by different people. Let's say the chair was manufactured by buying the seat separately from the base, and separately from the feet, and separately from the textures, so the chair then was assembled together by a person who bought all those pieces from different people. The assembled chair then is set to sell. How does one buy it? What are the steps to perform this? How does each step look in the databases for where each asset exists?

*** [[User:Dzonatas Sol|Dzonatas Sol]] 19:31, 23 October 2007 (PDT)

= Primary Database Thoughts =

* In a decentralized system, there is always the potential net splits to occur. Methods need to be developed to prevent irrational assets or even broken referential assets. For example, one could require the complete form of an intellectual property be stored all in a single primary database with all related assets that constitute that form instead of being allowed to exist in multiple primary databases. [[User:Dzonatas Sol|Dzonatas Sol]] 23:07, 22 October 2007 (PDT)

* It is obvious that movement of tangible assets from one primary database to another primary database needs a cHTTP basis to communicate the move. [[User:Dzonatas Sol|Dzonatas Sol]] 23:07, 22 October 2007 (PDT)

* One way to avoid irrational assets is to allow secondary database be local to a primary database such that the secondary database stores abstract assets instead of the attempt to create irrational assets. I've done a similar scheme like this before on a very small scale, and I already know it is test cases with abstract assets are not as simple as to allow irrational assets. There are, however, less redundant sanity checks are needed with abstract assets locally to the primary database, and it reduces a load on the primary database with assets that would become tangible but actually remain transient. [[User:Dzonatas Sol|Dzonatas Sol]] 23:07, 22 October 2007 (PDT)

== Domains ==

A domain is a group of hosts that may contain assets or instances of assets that share a trust model. They may be a trust domain (the largest contiguous set of hsost sharing a trust model), a region domain (from the original Linden documents), a single server. A uniform domain is one that shares a closer relationship than the AWG model specifies... the Linden grid is a homogenous domain. A non-uniform domain is one in which the AWG model must be used for interoperation between at least some members.

Within a uniform domain, assets are normally referred to using UUIDs.

Between uniform domains, assets are referred to using URLs. THe host part of the URL is the DNS address of the host responsible for that asset (eg, a region or an asset server). The path is unspecified, it merely has to be unique. URI-encoded attributes may be appended to request particular properties, iterate over properties, and (through POST operations) update properties. A standard URI for creating a new asset must be available on any asset host.

An asset may have multiple instances. Each instance contains a COPY of the asset properties that the requestor is allowed to have, a reference (location property) to the original asset, and possibly a cached copy of the asset data. When an instance is created from another instance, the location property of the original asset may be retained in the new instance, or the second instance may become a new independant copy of the asset with a permanent local copy of the asset data... that is, the distinction between instances and assets is flexible.

Details of enforcing intellectual property rights are primarily of interest for groups implementing non-uniform trust domains. Permissions and other rights metadata are only informational between trust domains. This is not to say that IP law does not apply, but that trust domains implementing different trust models can not be compelled to implement all trust models. It is anticipated that most domains will implement an asset property indicating that the asset is not to be transferred into another trust domain.

*** - original content above from article space

This is good information. I like to see how this can be worked into other design documents such as {{AWG|Region Domain}}, {{AWG|Agent Domain}}, and even the components of those domains, like {{AWG|Region Store}}s or {{AWG|Agent Store}}s.

*** [[User:Dzonatas Sol|Dzonatas Sol]] 19:39, 23 October 2007 (PDT)

==== Avatar ====
Does the Avatar represent and agent, or a user? I think a user. The agent is a software construct which permits the user to interact with other portions of the system.

==== Component ====

==== Domain ====
* I replaced the label of the link to "AWG Domain rationale discussion" by "Domain rationale discussion". The use of "AWG Domain" creates terrible confusion and also conflicts with LL's use of the term. The page itself should be renamed too, but that's better done by its creator. --[[User:Morgaine Dinova|Morgaine Dinova]] 09:49, 20 October 2007 (PDT)

* The architecture proposed by LL also created a point of confusion in its use of "Organization Domains" ... there's some sort of dimensional incompatibility there with the use of "Domain" in "Agent Domain" and "Region Domain". [[Talk:Multiple_Domains|I wrote a little about this topic]] back in September when I looked at the diagrams from the first meeting. Organization is better thought of as an attribute within this architecture, because it is so orthogonal to the other domains. What's more, it's a composite attribute with many aspects: for example, a server could belong to company A, provide resources for the group B, and be located in colo C. Which is the Organization domain? There is no single answer. "Organization Domain" isn't a very cohesive concept. --[[User:Morgaine Dinova|Morgaine Dinova]] 10:11, 20 October 2007 (PDT)

==== Meta Data ====

==== Permissions ====

==== Region ====

==== Region Domain ====

==== Resource ====

==== Scalability ====

==== Service ====

==== Simulation (sim) ====

==== Stakeholder ====

==== Use Case ====

==== User ====

==== Utility ====

==== Viewer ====

==== Viewpoint ====

==== See Also ====

==== Pre 10-19-2007 content ====

* The title needs changing to something less specific, like "Glossary", because '''Viewer''' is certainly not a component of a grid. --[[User:Morgaine Dinova|Morgaine Dinova]] 09:29, 25 September 2007 (PDT)

* Added Services and Utilities to the list -- [[User: Zha Ewry|Zha Ewry]] 9/26/2007

* I didn't want to define these since they reference the Linden "implementation" but it would be good to define what is meant by "Central Utilities" and Identity, location, and currency.--[[User:Burhop Piccard|Burhop Piccard]] 17:55, 3 October 2007 (PDT)

* '''Page renaming'''
: As has been discussed on various occasions in AWGroupies and elsewhere, the parent page '''Components and Roles''' has evolved, and as a result it is no longer named appropriately. I would change it to one of the names that have been suggested (eg. AWG_Glossary) if I knew how to migrate its namespace tree as a unit, ie. including Talk, history etc, but I don't know how to do that. Anyone? --[[User:Morgaine Dinova|Morgaine Dinova]] 02:32, 12 October 2007 (PDT)

* did that. refactored page into [[IEEE 1471]] page and glossary page while i was at it. [[User:Dr Scofield|Dr Scofield]] 09:12, 12 October 2007 (PDT)
::* Thanks, that's hugely better. :-) --[[User:Morgaine Dinova|Morgaine Dinova]] 03:57, 13 October 2007 (PDT)

* Reformatted page to use small '====' section headings instead of labels, so that we can edit them one at a time, more scalable. :P --[[User:Morgaine Dinova|Morgaine Dinova]] 03:57, 13 October 2007 (PDT)

* DrS, I've reexpressed your additions under "Architecture" as '''architectural descriptions''' for some randomly-named "''message flow viewpoint''" (maybe it should refer to ''protocols'' or whatever, change as required). The terms for "documents" are in flux --- '''ADV''' for "''architectural descriptions and views''" is just a placeholder, although it seems to work well. Zero has already delivered those nice graphic '''ADV'''s that cover 2 or 3 different viewpoints, although the concerns aren't all that easy to identify in them precisely because they're all thrown in together.
:: The central idea (as in IEEE-1471, which is a synthesis of a billion approaches prevalent in industry), is that "'''The Architecture'''" doesn't in fact exist outside of our heads, and is only communicated in specialised views which reflect the concerns and bias of specific parties.

:: I am forced to admit that I find the bullet point above, simply, at some level incomprehensible. The architecture we are defining is not some platonic ideal. It is a set of formal, normative specifications which to the best of our human capacities specify precisely and unambiguously how to build a conformant implementation. The specifications, hold no viewpoint, they have no biases. They may result from the fusion of many viewpoints, the clash and resolution of many stakeholders, but the architecture is deeply and fundamentally the normative documents which define it and '''nothing else.''' Reifications and realizations of the architecture may deviate from the specifications, but that doesn't change the architecture at all. - [[User:Zha Ewry|Zha]]
::* That's not how the industry sees it Zha. The viewpoint-based approach of IEEE-1471 isn't something radical and new, it's just a distillation (and a very simple non-prescriptive one) of many standard approaches to defining architecture in use throughout computing. Even Zero has effectively used this method in his architectural diagrams, which express the architecture from 2 or 3 different viewpoints. There is actually no other way, no matter how hard you try: your document will always end up describing how the architecture addresses the concerns of a given viewpoint. If you claim that your "normative documents" cover everything salient in the architecture, then all you've done is put all those viewpoint-based descriptions together in one lump. You're not really disagreeing. :-) --[[User:Morgaine Dinova|Morgaine Dinova]] 00:32, 14 October 2007 (PDT)
:::* More importantly though, it allows us all to work separately/grouped but towards a common goal, instead of bickering about what should appear on a one single central document. And an added benefit: it can make it easier for LL to back-port ideas into SL1, since the concerns and solutions will be nicely factored out. Evolution is an important goal, as Zero has made clear. --[[User:Morgaine Dinova|Morgaine Dinova]] 00:41, 14 October 2007 (PDT)

* I added a use case defintion as used with AWG. A "use case" is a bit different since its not really part of the architecture but one of several tools for coming up with an architecture. I still think it goes here because I've tried to narrow the definition a little bit to the AWG context and avoid some of the common misuses of the term. --[[User:Burhop Piccard|Burhop Piccard]] 15:17, 15 October 2007 (PDT)
::* Very useful, as we bandy this term around a lot. :-) It begs for a definition of "user" now, and I can't find a useful one. --[[User:Morgaine Dinova|Morgaine Dinova]] 21:28, 15 October 2007 (PDT)
::* I removed the first external link, to Wikipedia, as it widened the possible meanings rather than narrowing them. The whole point of this AWG glossary is to make us all speak the same language, as the Tower of Babel effect was leading to some unnecessary arguments. External links act in the opposite direction in this case. I left in your second Wikipedia reference, but I don't think that that line helps at all, as it just says "throw in the kitchen sink". If you could revise the line to not need the link, that would be helpful. :-) Perhaps follow the form you set in [[Early_Stage_Usecase_Template|minimal template]] and add a [[Final_Stage_Usecase_Template|detailed template]]? --[[User:Morgaine Dinova|Morgaine Dinova]] 21:58, 15 October 2007 (PDT)

::: Yes, I'd like to create a final state template but its a bit trickier as it needs to be more tailored to the system. I don't think the link is really needed except as a reference for people wanting more information. I'll try to reword it. --[[User:Burhop Piccard|Burhop Piccard]] 09:35, 17 October 2007 (PDT)

* Zha, excellent addition to architecture: you've reconciled the differences through "point in time". Works for me. :-) --[[User:Morgaine Dinova|Morgaine Dinova]] 21:28, 15 October 2007 (PDT)

* I added the "domain" term but I don't think its quite right. Can someone with a better understanding update it? --[[User:Burhop Piccard|Burhop Piccard]] 11:09, 16 October 2007 (PDT)

* In general, skimming the glossary, it feels like we need to get a little more disciplined about how we toss around phrases. For example, "meta data" is defined in a way that only refers to meta data on assets. There are other places in the architecture where we might well want to talk about meta-data, and in fact, depending on exactly how we define and use asset, the meta-data, may or may not always be attached to the asset. Other examples which concern me are resource, where we provide an extremely scalabality centric perspective on resource, which, for example, ignores the common web notion of a resource. We describe, Identity as both an utility and a component. We describe one specific domain, and describe it, in fact in a way which contradicts Zero's diagram, which has two seperate regions domains, both operated by Linden Labs.
I can just go in and start hacking on these, but, I'm hoping the people who posted them will take a careful look at them first. -[[User:Zha Ewry|Zha]] 7:59 pm PDT, October 17, 2007

Core Grid Services, Protocols, and structure

2007-10-23T22:23:34Z

Zha Ewry: Renamed to include VAG

'''RENAMED'' [[Core Grid Services, Protocols, and Structures VAG]]

Core Grid Services, Protocols, and Structures VAG

2007-10-23T22:22:19Z

Zha Ewry: New page: (this is an initial draft so scope and focus are still fairly open. Please add comments to the Talk: VAG if you have slightly different viewpoints so we can try to converge on a comm...

(this is an initial draft so scope and focus are still fairly open. Please add comments to the [[Talk: VAG]] if you have slightly different viewpoints so we can try to converge on a common view. This discussion could also expose other similar VAG that are needed in this area --[[User:Zha Ewry|Zah]] 15:20, 23 October 2007 (PDT) )

=Purpose=

The Core Grid Services, Protocols and structure VAG focuses on the grid and web services, the protocols and the overall structure of the AWG's work. Particular attention is focused on creating designs and architecture which is consistent with the nature and approaches of the World Wide Web.

See the [[Architecture Working Group]] and the [[Viewpoint Advocacy Groups]] for more information.

=List of concerns addressed by this viewpoint=
* Modeling services via REST
* Best practices in Web Services Design
* Appropriate uses of C-hhtp, Escrow, and capabilities
* How to handle continuing streams of events (pub/sub) in the architecture
* The overall shape of the design, including concepts such as domains, proxies and computational boundaries.

=Areas not addressed by this viewpoint=

* Implementation of core components behind the architectural boundaries. We will examine such items only to the extent that they drive our core concerns.

* Underlying representations of 3d objects. We may examine efficient encodings, but we will defer 3d issues to the [[Geometry and Physics VAG]]

=Source of Viewpoint=

=Use Cases=

See the [[Architecture Working Group Glossary]] and [[usecase templates]] for more information on creating usecases. One liners are fine (and better than nothing) but more detail will result in a better understanding and a better architecture.

* Category 1
** Use case a
** Use case b

* Category 2
** use case c
** use case d

=Related JIRA Issues=

The following JIRA issues are known problems that this VAG would like to see resolved in any future architecture. The purpose of this list it to avoid problems that exist in the curent architecture. The more typical JIRAs that are more short term in nature or can be resolved by simple code or design change should not be listed here.

* JIRA1
* JIRA2

=Organization=

== Joining ==

Anyone with an interest in this Viewpoint is welcome to join. You should join the [[AW_Groupies]] group in Second Life.

== In world meetings ==

We meet once a week in-world and more if people are available.

Also members are active on the wiki and in the SLDEV mailing list.

Meetings are scheduled via the "[http://www.google.com/calendar/embed?src=pdd5mpktklo89bgmfgi076mcc4%40group.calendar.google.com SL AW Groupies" google calendar]"

===Meeting Agendas===

* TBD

===Chat Logs===

* TBD

== Modeling Techniques used to express viewpoint ==

None decided.

=External Links=

=Members (Stakeholders)=

:[[User: Zha Ewry| Zha]] - Founder

Viewpoint Advocacy Groups

2007-10-23T22:21:24Z

Zha Ewry: /* List of VA-Groups */

(This is an early draft document, created for feedback purposes. It does not yet reflect a consensus recommendation, or statement of policy at this time. However, a number of VAGs have been [[Viewpoint Advocacy Groups#List of VA-Groups|defined]] and are in active use.)

Stakeholders in the Architecture have various agendas, goals, and viewpoints. These views are critical to the design of the new grid. This proposal is to create groups to focus on specific requirements. The list of Viewpoint Advocacy Groups may grow and shrink during the course of this project. The idea here is to provide a framework to address specific concerns in a systematic way.

"Membership" in a group is not exclusive. Anyone can participate in as many or few groups as they deem appropriate. Participation in a Advocacy Group does not imply lack of participation in the core AWG, which is merely an umbrella for all working subgroups.

== Organizational structure for Viewpoint Advocacy Groups ==
Proposed organizational structure and definition of VAGs is under discussion on the [[Talk:Viewpoint_Advocacy_Groups|Talk page]]. All contributions welcome.

== Purpose of Viewpoint Advocacy ==

The purpose of Viewpoint Advocacy within the AWG includes the following:

:* To base architectural decisions on use cases via viewpoints.
:* To establish requirements from the concerns in each viewpoint.
:* To integrate the work of the separate viewpoint advocacy groups.
:* To document, negotiate and resolve any conflicting concerns.
:* To produce a coherent architecture that conforms with the above.

A successful Viewpoint Advocacy Group requires:

:* To present a set of related concerns about the system in the form of a clear viewpoint.
:* To document architectural specifications that stem from this viewpoint.
:* To consider the architectural needs of likely implementations that fulfill the specifications.
:* To operate in a way that allows for alternate implementations that satisfy the viewpoint.
:* To work with the core goals to document views and requirements that conflict or are inconsistent.
:* To review the core goals against the work output to ensure that the view's requirements are met.
:* The end result of the above is an architectural description which reveals the architecture from this viewpoint.

== Defining a Viewpoint ==
A good viewpoint might include the following elements: (borrowing freely from [http://info.acm.org/sigada/conf/sigada2000/private/SIGAda2000-CDROM/SIGAda2000-Proceedings/Emery-Architecture-Presentation.pdf Emery]):

: '''Required''':
::* Name of the viewpoint
::* List of stakeholders holding this viewpoint
::* A statement of areas included and excluded from the viewpoint
::* List of concerns addressed by this viewpoint
::* Language, modeling techniques, representation method or tools used within this viewpoint
::* Source for the viewpoint
::* Use Cases
: '''Optional''':
::* Consistency/completeness tests for the viewpoint
::* Evaluation/analysis techniques
::* Heuristics, patterns, other guidelines
::* Estimation of associated cost in resources

== List of VA-Groups ==

* [[Event Scalability VAG]]
* [[Geometry and Physics VAG]]
* [[Core Grid Services, Protocols, and Structures VAG]] (REST, c-http, escrow, capabilties, and core protocols)
* [[Live Performances VAG]]
* [[Quality Assurance VAG]]
* [[Scalability VAG]]

Core Grid Services, Protocols, and structure

2007-10-23T22:17:36Z

Zha Ewry: Core Grid Services, Protocols and structure

Viewpoint Advocacy Groups

2007-10-23T22:03:58Z

Zha Ewry: /* List of VA-Groups */ Merged a few empty VAGS to get a useful one

(This is an early draft document, created for feedback purposes. It does not yet reflect a consensus recommendation, or statement of policy at this time. However, a number of VAGs have been [[Viewpoint Advocacy Groups#List of VA-Groups|defined]] and are in active use.)

Stakeholders in the Architecture have various agendas, goals, and viewpoints. These views are critical to the design of the new grid. This proposal is to create groups to focus on specific requirements. The list of Viewpoint Advocacy Groups may grow and shrink during the course of this project. The idea here is to provide a framework to address specific concerns in a systematic way.

"Membership" in a group is not exclusive. Anyone can participate in as many or few groups as they deem appropriate. Participation in a Advocacy Group does not imply lack of participation in the core AWG, which is merely an umbrella for all working subgroups.

== Organizational structure for Viewpoint Advocacy Groups ==
Proposed organizational structure and definition of VAGs is under discussion on the [[Talk:Viewpoint_Advocacy_Groups|Talk page]]. All contributions welcome.

== Purpose of Viewpoint Advocacy ==

The purpose of Viewpoint Advocacy within the AWG includes the following:

:* To base architectural decisions on use cases via viewpoints.
:* To establish requirements from the concerns in each viewpoint.
:* To integrate the work of the separate viewpoint advocacy groups.
:* To document, negotiate and resolve any conflicting concerns.
:* To produce a coherent architecture that conforms with the above.

A successful Viewpoint Advocacy Group requires:

:* To present a set of related concerns about the system in the form of a clear viewpoint.
:* To document architectural specifications that stem from this viewpoint.
:* To consider the architectural needs of likely implementations that fulfill the specifications.
:* To operate in a way that allows for alternate implementations that satisfy the viewpoint.
:* To work with the core goals to document views and requirements that conflict or are inconsistent.
:* To review the core goals against the work output to ensure that the view's requirements are met.
:* The end result of the above is an architectural description which reveals the architecture from this viewpoint.

== Defining a Viewpoint ==
A good viewpoint might include the following elements: (borrowing freely from [http://info.acm.org/sigada/conf/sigada2000/private/SIGAda2000-CDROM/SIGAda2000-Proceedings/Emery-Architecture-Presentation.pdf Emery]):

: '''Required''':
::* Name of the viewpoint
::* List of stakeholders holding this viewpoint
::* A statement of areas included and excluded from the viewpoint
::* List of concerns addressed by this viewpoint
::* Language, modeling techniques, representation method or tools used within this viewpoint
::* Source for the viewpoint
::* Use Cases
: '''Optional''':
::* Consistency/completeness tests for the viewpoint
::* Evaluation/analysis techniques
::* Heuristics, patterns, other guidelines
::* Estimation of associated cost in resources

== List of VA-Groups ==

* [[Event Scalability VAG]]
* [[Geometry and Physics VAG]]
* [[Core Grid Services, Protocols, and structure]] (REST, c-http, escrow, capabilties, and core protocols)
* [[Live Performances VAG]]
* [[Quality Assurance VAG]]
* [[Scalability VAG]]

Talk:AWG Scalability through reverse proxies: the paravirtual grid

2007-10-23T13:12:26Z

Zha Ewry:

=== Analysing scalability of the paravirtual grid ===
Call me confused, but I don't see much scalability in the paravirtualization of the Grid... The reverse proxies are called quasi-static caches, but the problem is that the simulation data, the way it is now in SL, is not static enough to make it practical or useful. As I understand it, this proposal is a form of sharding of the regions, it does not solve high concurrency number issues because of two reasons:
* The subdivision method exemplified (US, Europe, Asia) is useless in current use cases: different continental populations log in SL and interact at roughly the same hours of the day across themselves already. Thousands of people connecting from the same geographical origin are still facing asset lag and simulator cutoff. This means that the proposal does not really address the concurrency problem at all, or at least it only addresses a marginal aspect of it.
* Even if we take exemption of the above problem by redirecting same-origin excess load to other reverse proxies, the data streams are still mixed as high in the chain as the origin. i.e. the load that arises from the interaction and intervisibility of the crowd still has to be processed by the source, and we're just moving the bottleneck from the simulator to this interconnection mechanism.

Even if there is a way to seperate the data streams at the source and keep them seperate down the way (which implies seperating people into seperate grids where they cannot see each other) this proposal does not actually offer any mechanism for the accruing of those streams at the "top" of the architecture: there is no method proposed for concurrent modification of the central databases, which therefore still faces the same scalability issues known today. Besides, bottlenecks are still present inside the proposed architecture: they appear within the flow of data from the source, be it a reverse-proxy or the original simulator, and the clients. This is bound to happen with any form of static subdivision (geographic or not), and dynamic subdivisions can only mitigate that effect: the distribution of the load in SL is not uniform in any globally-determinable way, so there is no correct way to distribute that load from the top-down, it must be done from the clients in a bottom-up way.

In other words, I think trying to approach concurrency issues in SL through a macroscopic view, and thinking of the population load in global aggregates, is not the correct method. The bottom line is that the elementary design of Grid processes determines everything else, including the global result. I'm afraid LL might be making the same mistake in their own proposal [https://wiki.secondlife.com/wiki/Multiple_Domains#How_it_might_scale_in_both_domain_types here]: in many common use cases, it does not, in fact, scale the way they hope it will. Simply throwing more machines at the growing Grid load does not appease it, the fundamental origins of the scalability constraints, within the design of the Grid processes, as they had been identified months ago, have to be addressed first.

I hope this can help improve the proposal. Reverse-proxies definitely have their place in a well-designed Grid architecture, finding exactly how is an important task. --[[User:Jesrad Seraph|Jesrad Seraph]] 04:11, 23 October 2007 (PDT)

This analysis feels about right. I've been chewing on some of this in these two pages
: [[AWG: state melding exploration]]

:[[AWG: Core simulator exploration]]

Which try to look at two levels of abstraction, at what the core work of a regoin simulator is. (Rough draft warning) -- [[User:Zha Ewry|Zha]]

Talk:Viewpoint Advocacy Groups

2007-10-23T02:18:04Z

Zha Ewry: /* More groups than participants here */

== Organizational structure of VAGs ==
* I moved this discussion here since point-counterpoint and attribution tagging are both inappropriate in the main namespace, and the discussion was obscuring the information on the page as well. --[[User:Morgaine Dinova|Morgaine Dinova]] 06:40, 19 October 2007 (PDT)

Here is a proposed organizational layout of the VAGs:

[[Image:vag-org.png | 400 px]]

Here is a conceptual layout of the VAGs:

[[Image:vag-concept.png | 400 px]]

:* The above picture places areas of concern into separate boxes, and then defines groups which cross-cut over one or more of them. This makes it topologically identical to the structure of our existing VAGs, except for the fact that the layout of the boxes (which may have been only for simplicity) is flawed because it shows the areas of concern as disjoint, which they most certainly are not. In contrast, the existing VAGs reflect the reality that concerns are intertwined in extraordinarily complex ways in any non-trivial system like SL. --[[User:Morgaine Dinova|Morgaine Dinova]] 18:07, 18 October 2007 (PDT)
::* It's easy to demonstrate how the existing VAGs achieve exactly what you want but without the incorrect disjointness in the model. The [[Scalability VAG]] highlighted right from the start that further subgrouping was expected, so I'll do that for you now as an illustration. Event scalability is ''exactly'' the kind of user-oriented concern which you advocate, so it now has its own [[Event Scalability VAG]]. -- '''DONE''' --[[User:Morgaine Dinova|Morgaine Dinova]] 20:37, 18 October 2007 (PDT)
::* The benefit of having an umbrella parent is immediately apparent, since only the new and more specific concerns of the new sub-VAG need to be defined, and everything else can be inherited. What's more, the more technical working group of the parent can supply the traceable documents/views required by the sub-VAG, even if this is beyond the competence of the (possibly non-technical) members of the latter. I see a lot of benefits to this structure. --[[User:Morgaine Dinova|Morgaine Dinova]] 19:47, 18 October 2007 (PDT)
:: So you'll have Event Scalability sub-VAG, Event Security sub-VAG, Event Physics Sub-VAG... Since event people have concerns in all those areas. My proposal is to just have "Events VAG", and they will touch on all the issues. [[User:Gigs Taggart|Gigs Taggart]] 22:28, 18 October 2007 (PDT)
::* Oh, I'm all for an Events VAG, since that reflects a particular viewpoint. However, that is such a colossal area that it will split very rapidly into Mass Events VAG (focus on crowd packing), Interactive Events VAG (focus on speed and control), Spectator Sports VAG (focus on non-interactive events in stadiums), Observer Mode VAG ([[Use_Cases#SecondlifeTube]]) and many others, mostly referenced to their parent for sanity. And that's precisely the structure I set up for the scalability-oriented VAGs, so no disagreement there, except for the matter of disjointness of architectural areas which is simply incorrect. --[[User:Morgaine Dinova|Morgaine Dinova]] 04:34, 19 October 2007 (PDT)
::* I took your suggestion on board and started composing an Events VAG. It immediately became apparent that this served no purpose whatsoever. Every gathering of people is an event, and if you look at the astronomic spectrum of possible event types, there is very little commonality indeed. I thought I might find use for an Event VAG as an umbrella group, just to simplify subgroups, but even that fell through because events vary so hugely that the only common elements are those that apply to everyone in SL. However, your idea did lead me to create one specific event-based VAG, as follows. --[[User:Morgaine Dinova|Morgaine Dinova]] 05:07, 20 October 2007 (PDT)
::* The [[Live Performances VAG]] now exists to focus end-user concerns in the various areas of live performances into a cohesive viewpoint. --[[User:Morgaine Dinova|Morgaine Dinova]] 05:07, 20 October 2007 (PDT)

Note these groups are just examples of what a group might be. Notice that high level architectural issues are not VAGs, rather, all VAGs will consider high level architectural issues from their unique viewpoints. For example, "Security" is not a viewpoint, so a "Security" VAG would make no sense. All viewpoints will consider security in their own unique way, and provide input.

:* It's precisely to avoid the "everyone considers everything in the architecture" problem that we have subgroups. We actually started off without subgroups, you may recall, and there was a huge amount of heat verging on warfare because the different viewpoints of different people prevented collaboration --- this is why we defined VAGs with cohesive interest sets in the first place. It wasn't out of our love for paperwork. We found a desperate need for isolation of concerns. --[[User:Morgaine Dinova|Morgaine Dinova]] 18:07, 18 October 2007 (PDT)
::This isn't "Everyone considers everything", it's "Everyone considers all the parts of the architecture that are relevant to their stake, from the point of view of that stakeholder." It's a subtle but important difference. [[User:Gigs Taggart|Gigs Taggart]] 22:37, 18 October 2007 (PDT)
:::* Which of course defines the existing 4 VAGs very nicely. :-) --[[User:Morgaine Dinova|Morgaine Dinova]] 04:43, 19 October 2007 (PDT)

VAGs can be a way to bring less technical people into the fold and get their valuable input. You do not need to understand the technical issues to provide input into a VAG. The VAG delegates, however, should understand the technical issues involved in fulfilling the architectural requirements of a viewpoint, as this will be required in their participation in the core AWG.

:* I'm fine with that, although the hierarchy implied by "delegates" admitted to the inner sanctum of "core" isn't helpful. I would expect the flatness of a VAGs-only model to work better in our non-corporate workgroup. I don't fee strongly enough about it to object though. My other two points above are much more fundamantal. --[[User:Morgaine Dinova|Morgaine Dinova]] 18:07, 18 October 2007 (PDT)

:* Gigs - thanks for putting this together. I like the VAG being more "user" oriented than "programmer" oriented. In my mind we ultimately need clear set of use cases. I would see each VAG responsible for defining these use cases and synthesizing them into something the architects can use. So, in theory, having a "Builder" VAG seems closer to the user than a "Geometry and Physics" VAG. Now here is where I start to have a harder time because there are so many builders with very little in common. We have prim builders using the SL tools, numerous Sculpted Prim tools, people using Maya and blender, people wanting to "build" by exporting from other tools (i.e mechanical CAD), people wanting to build from different viewers, and people eventually wanting to import from other VWs. You would also have viewpoints from programmers wanting to do this with an API and users wanting better UI. So really, you would need a number of VAGs for building and probably a couple more for other types of creation (maybe that is ok). Maybe being a programmer, I can't separate myself so completely from the architecture. Its hard not to think from the stand point that we have a geometry sub-system and what are the use cases for interacting with it. --[[User:Burhop Piccard|Burhops Piccard]] 20:12, 18 October 2007 (PDT)
::Well, in my vision, you'd have to decide what level of granularity is appropriate there. The VAGs aren't going to be without internal differences of viewpoint, but in the end the stake should be the same: You all want to do "foo", where "foo" is whatever the VAG is about. You'll still have to consider all the use cases to accomplish "foo" that you are aware of, even if no one in the group does it ("it" being that particular use case to accomplish "foo") personally. [[User:Gigs Taggart|Gigs Taggart]] 22:31, 18 October 2007 (PDT)
::: Yes, I think I agree with that. So in my example above FOO = "more easily creating better geometry". So, horizontal/vertical model is not quite right to me (sorry I'm slow Morgaine :-) There are certainly some VAG that do fit this and I agree that VAG should not purposely try to mirror the architecture. But I'm starting to feel the VAGs should look a bit more like this:

[[Image:vag-org2.png | 400 px]] (Note: the red lines are mostly random. I'm not trying to suggest any VAGs here.) --[[User:Burhop Piccard|Burhop Piccard]] 09:17, 19 October 2007 (PDT)
:* That's fine by me, Burhop. It takes us back to where we were initially, where a VAG's concerns may address any area of the system as required, without prior constraints. In other words, system areas are enumerated vertically, and if the list is complete then it serves no purpose since it will then mean "everything", which is correct. Good luck trying to keep the list complete though. :-) --[[User:Morgaine Dinova|Morgaine Dinova]] 09:31, 19 October 2007 (PDT)

== Viewpoints: the substance behind the concept ==
If you take a few steps back from our metadiscussion above and look at what's being happily accepted from the very relaxed guidelines of IEEE-1471 and what's being omitted, the picture that emerges is a curious one. It reminds me of Feynman's story about "cargo cult science", in which the protagonists accept the form but don't understand the function that underpins it.

IEEE-1471 deals with architectural design of systems, yet it is based on the concept of '''viewpoints''', which at first glance have nothing at all to do with architecture --- mighty peculiar! It doesn't require a lot of reading to discover why this is so though: it's because you can't really define architecture in any other way, no matter how hard you try, and no matter how convinced you are that you are doing it objectively and independent of viewpoints. You are satisfying only one viewpoint --- your own, or multiple viewpoints of your own, or of your own interest group.

Implicit in that concept is that you can't subdivide up architecture in a single way ''a priori'' and then dish out pieces of it to various working viewpoint groups. If you could make such a subdivision then that would imply that your unique breakdown already models architecture to first order, either functionally or structurally, in which case viewpoints aren't being used in their IEEE-1471 role of delivering architectural descriptions at all, because it's predetermined.

Accepting only the ''process'' of viewpoints really isn't very helpful. Viewpoints aren't really a process in IEEE-1471 at all, just a consequence of understanding that there can be no architectural description independent of them. What this means is that accepting ''viewpoints'' yet still believing in some kind of overriding decomposition is completely missing the core point of IEEE-1471. You might as well have no explicit viewpoints at all.

Viewpoint groups '''define''' the breakdown that is most appropriate to them. That's their purpose. 
--[[User:Morgaine Dinova|Morgaine Dinova]] 08:19, 19 October 2007 (PDT)

* It's worth noting that the pictures above don't necessarily have to represent ''a priori'' architectural breakdown at all, but merely a vertical enumeration of areas of interest, all necessarily intertwined because they cannot be disjoint. The intersection of vertical VAG lines with the horizontals then represents exactly the structure of the 4 existing VAGs (and IEEE-1471 viewpoints in general), in that any viewpoint can involve consideration of any area of architecture. In other words, the breakdown contributes no new information, while limiting the scope of VAGs to only those elements listed. (And if they're not limited in scope, then why bother with the list?) It achieves nothing. --[[User:Morgaine Dinova|Morgaine Dinova]] 09:18, 19 October 2007 (PDT)

== Naming of Viewpoint Advocacy ==
* I am actually very serious about the slight rename of V.A.G. to V.A.T., as light-handedly discussed on the group chat. [[User:Dzonatas Sol|Dzonatas Sol]] 16:13, 11 October 2007 (PDT)

:: Could you elaborate on the reason for the name change? I see the comment "to keep focus of the right direction, keep in mind about COST, and avoid bureaucracy" but don't quite understand how the name change accomplishes this. --[[User:Burhop Piccard|Burhop Piccard]] 17:56, 11 October 2007 (PDT)

::: It implies a meaning from recent events, which are significant; however, the name change alone is not a complete solution. It is a minimal change to influence the discussion. The serious point being task focused and cost effective. The Tao Of Linden already points out the need to not be political. Zero also reiterated about the need to have no ego in code. The emphasis of "groups" and "core AWG" can easily be a politicized medium, and we want to avoid that. We need to stay a team altogether. In AWG chat, we found the intention is not to actually form (sub)groups, but the intent is more to (to quote the article), "Document rationale for architectural decisions" and "Work with the core goals to document views and requirements that conflict or are inconsistent." It is inconsistent and political to form more subgroups to do what the AWG already does. JIRA is an example of a better medium then subgroups -- create tasks and subtasks. Again, COST is not something I've seen discussed. COST is an influence here. In fact, a good example of a use case is the recent event between Europe and non-EU currency transactions. Hmm, what's a good way to say it with too many details... look at [[ArchWG_Mtg_1_Slides]] and create an analogy of "mainland" to the U.S. -- and remember that the pipe between US and EU is limited. Then you'll get the notion that the "V.A.G." (as previous defined) IS the AWG. The question becomes, why change it from "A.W.G" to "V.A.G."? [[User:Dzonatas Sol|Dzonatas Sol]] 19:07, 11 October 2007 (PDT)

:* I very much support the idea of working on tasks, rather than belonging to a group. I intend to work on (or have an interest in) numerous tasks, maybe all of them to some degree, so group membership isn't a very helpful concept in this. --[[User:Morgaine Dinova|Morgaine Dinova]] 23:21, 11 October 2007 (PDT)

* Dzonatas' point about "groups" vs "core AWG" potentially creating a dangerous politization is very important. By placing all concerns into their own VA task groups, including those who some feel are "core", the entire structure is flattened and all choices have to be justified equally. The "core" tasks (and the groups working on them) will then no longer be special, but simply represent those concerns that we have agreed on ''a priori'', like using REST. This is a much cleaner and less adversarial project structure, in my view. --[[User:Morgaine Dinova|Morgaine Dinova]] 23:32, 11 October 2007 (PDT)

:* I've just realized that we're editing in User:Gigs space at the moment. You might as well promote it to main namespace. It's not like on Wikipedia where you'll get 500 people screaming blue murder at you. ;-))) There weren't any dissenting voices in the AWGroupies chat against this, nor competing ideas. --[[User:Morgaine Dinova|Morgaine Dinova]] 08:54, 13 October 2007 (PDT)

::* It was moved from V.A.G. to V.A.T. back to V.A.G., which shows a concern. Also, Gigs stated below "These aren't tasks" where in group chat I thought we agreed on the task perspective. That doesn't seem true (anymore?). This seems like the best place to work with this idea. We've had other pages moved to users pages on this wiki, so this is doing just likewise. [[User:Dzonatas Sol|Dzonatas Sol]] 09:22, 13 October 2007 (PDT)
:::* I honestly don't think that there is any ''effective'' disagreement here among the entire set of participants. Ultimately the same static pages have to be edited, and it doesn't matter how those evolving documents are viewed. Those whose view is task-based will multitask between their various pages of interest, and those who are group-oriented will see themselves as belonging to one or more groups. I think this will work! :-) --[[User:Morgaine Dinova|Morgaine Dinova]] 05:38, 20 October 2007 (PDT)

== Groups ==

To be clear, we ARE talking about groups here. We have groups of stakeholders with their own concerns. These aren't tasks, they are groups.

You all mention "politicization" ... Groups of people will want certain things, depending on what their stake is. Trying to deny that is just going to lead to a lot of useless bickering. This is supposed to be a framework for various groups to advocate their viewpoint and to ensure that their requirements are met as best we can.

It's supposed to be slightly adversarial, in the same sense that a prosecuting attorney and a defense attorney are adversarial. It doesn't mean they can't go have dinner together after the trial, or even switch roles in the next trial. We are all working toward the same end, but that doesn't mean we all need to advocate the same viewpoints.

Membership in one of these groups isn't exclusive, and there's no reason one person can't be a member of more than one group, or a member of one of these groups and also of the core team. In that sense it isn't polarizing, since there's nothing preventing participation anywhere that someone wants to participate. It's merely a construct to provide a way of thinking about stakeholder groups, their needs, and integrate them into the design.

I'm renaming this back to groups.

[[User:Gigs Taggart|Gigs Taggart]] 11:47, 12 October 2007 (PDT)
::These groups should have their own meetings, and produce their own output. This allows for a finer grained focus than one huge group with many stakeholders all trying to pull the group in their own direction. I expect most of these subgroups to be from 3-7 people. This is an ideal size for actually getting things accomplished. Larger groups are REALLY BAD at getting anything done. [[User:Gigs Taggart|Gigs Taggart]] 11:58, 12 October 2007 (PDT)

* I think this is a fine idea. I like the idea of having organized groups feed in specific use cases and requirements, rather than a central group needing to do a ton of heavy lifting. I don't think Linden Lab can facilitate all of this, but we certainly don't want to obstruct it. -- [[User:Rob Linden|Rob Linden]] 12:59, 12 October 2007 (PDT)

* I support these well-focussed viewpoint groups because they can help reduce arguing over a single spec document, and therefore raise the spirit of collaboration. :-)
:: As you say, it can be seen as slightly adversarial, but I put quite a different slant on it because of my past history: engineering requirements are '''ALWAYS''' in conflict with each other, and therefore require cooperative assessment and calm, professional tradeoffs to be made. These viewpoint groups allow us to approach that structurally, but only if the structure is flat and the playing field level. One issue illustrates this: we've already seen some people express that their concerns and work are so "core" that they don't even need to describe a viewpoint because "core" overrides everything else. That approach does not create an atmosphere of collaboration, which is why I want everyone to buy into your idea rather than consider themselves above it. --[[User:Morgaine Dinova|Morgaine Dinova]] 07:58, 13 October 2007 (PDT)
::Nothing is above the VAGs. The VAGs will review the work output of the core group in every way. If the core group is proposing something that a particular VAG can come up with a coherent critique on, then that should be reexamined. [[User:Gigs Taggart|Gigs Taggart]] 22:57, 13 October 2007 (PDT)
:::* Sounds fine to me then Gigs. :-) If nothing is above the VAGs, then "core" must either have no hard design issues associated with it at all (since it involves no concerns/tradeoffs), or else it must be a VAG since it will necessarily express a viewpoint. :-) --[[User:Morgaine Dinova|Morgaine Dinova]] 01:08, 14 October 2007 (PDT)

::::* There are still concerns here that have not been addressed. If the "calm, professional tradeoffs to be made" are to ignore views as done here then how can we expect these groups to fulfill the overall requirements? How can we expect them to even fulfill the goals listed on the article when the implementation of these VAGs don't even follow such viewpoint design? We can't expect that. Again, I reiterate the need to avoid any kind of politics here by these groups. We already found problems in attempts to go forward with the current VA-groups. There is lots of thoughtful work being done that I hate to see go to waste by being misdirected or being too limited. We need a simple flat foundation to begin. Let the elements of the foundation not be limited by these groups. I understand the concern over one large group, and we obviously agree there needs to be a way to break it down. I believe it can be done by more technological method than by a need to form these subgroups. [[User:Dzonatas Sol|Dzonatas Sol]] 08:22, 18 October 2007 (PDT)
:::::* Dzon, I agree 100% with the goals that you mention above ... yet I can't find anything here in conflict with those goals! Surely the huge problem isn't merely "group" vs "task"? I was happy with it reverting to VAG after the change to VAT because it makes no '''actual''' difference to what we're doing --- we're still going to define the viewpoints, regardless of whether this has a group or a task focus. They're two sides of the same coin, as I see it. :-) --[[User:Morgaine Dinova|Morgaine Dinova]] 13:44, 18 October 2007 (PDT)

:::::* If you remember, Gigs even stated in group chat that this being a wiki and feel free to edit it instead of any statement to address the concerns, and that is exactly what occurred here. It was edited to express the concerns. AWG is already a "group." There is no clear viewpoint or clear view to why we need specific subgroups. The subgroups, as suggested by VAG structure, create potential politicization. I also addressed further concerns about that in the above paragraph. Where is the viewpoint that created this VAG implementation? Where do you see "core AWG" defined and why needs there be a "core AWG"? Are they a self appointed group or who appointed them or is all members "core"? I can think of several questions to ask. How are resources set up for these subgroups? What happens when a viewpoint spans several concerns from several groups? Where is the JIRA resource to individualize each issue? ...? We can create viewpoints without subgroups, but if there is a need for a subgroups then "eat your own dog food" and start with the viewpoint/use case for it and address the concerns. I also suggested on the AWG Process talk page to setup "office hour" style times that would be friendly to specific geographical area, and let those discussions work with those agendas. [[User:Dzonatas Sol|Dzonatas Sol]] 14:36, 18 October 2007 (PDT)

::::::* I'll ignore the Office Hours timetabling here, not because it's unimportant but because that's a matter for each subgroup to define since it is a function of where their members happen to live. The ability to timetable in a manner that satisfies everyone in a group is inversely proportional to the size of the group, which is a small but not insignificant benefit of subgrouping.
::::::* I'll try to answer your other questions though:
:::::::* AWG is certainly a group, but it's a group with such a broad remit that it functions poorly without paritioning, which I'll explain in relation to your second point.
:::::::* Your claim that "There is no clear viewpoint or clear view to why we need specific subgroups" is quite wrong: the need for subgrouping emerged out of a direct and very overt requirement. AWG started off without subgroups, and this led to a considerable amount of heat and near warfare as a result of the very different viewpoints and interests of the participants. We '''expressly''' chose to subgroup along viewpoint lines to avoid this problem, which was quite literally destroying collaboration as well as wasting everyone's time in the IM channel. That was the reason why, and it was exceedingly important.
:::::::* Re politization, VAGs don't add any more of it: at the end of the day, every non-trivial project has conflicting requirements, and they need to be reconciled in a satisfactory engineering manner through tradeoffs. The benefit of subgrouping however is that this difficult process only happens after the concerns have been well quantified, whereas without subgrouping you end up with the same discussions throughout the whole project and before anyone really knows in depth what they're talking about.
:::::::* The viewpoint that created this viewpoint system doesn't exist because we picked the nearest solution to hand that addressed our (rather bad) problem. Rather than getting involved in more divisive discussions, we coopted the basic elements of IEEE-1471 as several people seemed happy with them, and nobody else offered any alternatives. There wasn't a conspiracy nor a diktat. :-)
:::::::* I have no idea what "core AWG" means, nor what it's meant to accomplish, nor how it can do anything but cause division. The VAG model simply puts everyone's concerns into their own viewpoint groups, including those people who may have considered themselves to be "core" and thus special. With VAGs they are no longer special, yet their concerns are still met. Everyone wins.
::::::* I can't really comment on the other issues. I am however concerned that we're spending so much wiki time on metadiscussions. VAGs aren't perfect, but they're adequate. I don't see a big problem. --[[User:Morgaine Dinova|Morgaine Dinova]] 19:23, 18 October 2007 (PDT)

== More on groups vs tasks ==
* The implementation of these VAGs need their own viewpoint and views (not the suggested views/viewpoints from the VAG itself); however, the concerns listed on the VAG page have not been addressed. That already sets a bad example for any future views. The design and model of these VAGs just have not been completed because concerns have been ignored. [[User:Dzonatas Sol|Dzonatas Sol]] 07:43, 18 October 2007 (PDT)
:* Transplanted from the main namespace of [[Quality Assurance VAG]], where it was clearly off topic since it is not a concern within that viewpoint. It's a good point, but made in the wrong place. This would appear to be the most suitable location. --[[User:Morgaine Dinova|Morgaine Dinova]] 13:33, 18 October 2007 (PDT)
:* Dzon, I didn't see your last entry in the section above, or I would have responded, sorry. As you can see in the section above though, I don't actually understand the problem that you're highlighting. I do want to. :-) The actual VAG work seems to be progressing smoothly, and I can't see any structural faults with it yet. Maybe you could describe the problem you see in the context of an existing VAG, as an illustration? --[[User:Morgaine Dinova|Morgaine Dinova]] 14:03, 18 October 2007 (PDT)

== "Eat your own dog food" ==

I can already see the politics started with "groups" and this is one area we don't need those kind of politics. Even as Rob suggested that LL does not have the means to facilitate. If you want groups Gigs, I suggest you document this more -- "eat your own dog food." I believe there is enough on the front article to know what to include when you write your viewpoint. At this time it is not complete enough, and it be better to have more to understand each other rather than wheel war about it. I think I've written more on this discussion than what you wrote in the article, and maybe that should say something in itself, especially if I continued into further details. I'm looking for your details of your viewpoint. What I changed into "tasks" is the attempt to use modern technology that is already provided to achieve the same goal without the politics, but you don't see that. [[User:Dzonatas Sol|Dzonatas Sol]] 07:44, 13 October 2007 (PDT)

* I don't mind either way. The '''viewpoints''' are the central idea here (and I didn't invent that). Of course the people gathered around a viewpoint form a group. And what they do is a task. But it's not worth arguing about the name. Just get everyone to subscribe to one or more viewpoints (very lightweight!!), and all will be fine. :-) --[[User:Morgaine Dinova|Morgaine Dinova]]

:* Yes, it can be very simplified in that view. Modern technology allows easy subscription and *bam* you have the groups automatically behind it. I see no reason to actually define the groups, but there is reason to define the tasks and worry about cost. [[User:Dzonatas Sol|Dzonatas Sol]] 08:09, 13 October 2007 (PDT)
::* Good point about cost. I'll add that to the general template that's emerging for defining viewpoints. "Regions on Mars" might denote an interesting viewpoint, but its cost field might have some bearing on its viability. ;-))) --[[User:Morgaine Dinova|Morgaine Dinova]] 08:18, 13 October 2007 (PDT)

== Viewpoints and the inter-VAG reference graph ==
In working on various VAGs, I've noticed that an interesting inter-VAG inheritance/composition/reference graph is emerging:
:* Some VAGs are devolving by decomposition into sub-VAGS: ''eg.'' the [[Scalability VAG]] quite naturally decomposes into one sub-VAG per dimension of scalability. The [[Event Scalability VAG]] is already such a sub-VAG and brings together a very focussed and useful viewpoint, while inheriting many elements from its parent VAG. The resulting relationships are the usual ones found in inheritance and composition graphs.
:* Some user-level VAGs express concerns that necessarily cross-cut across numerous quite different areas of system architecture, function, and performance, and so these VAGs couple by reference to any number of other VAGs. Using the [[Live Performances VAG]] as an example, it expresses highly varied user-level concerns relating to live performances, and some of these are examined in more detail in the technical [[Event Scalability VAG]] to which it refers, while others might be examined in (say) a [[System Performance VAG]], an [[Avatar Control VAG]], and so on. This makes me see end-user VAGs as demultiplexers for spraying concerns into technical VAGs, to form a dense dependency graph.
:* The technical VAGs may each be focused on a specific viewpoint, but they're not disjoint. On the contrary, focussing on a given viewpoint necessarily implies reduced focus on other areas, which means that those other areas are open to coverage by other VAGs, to which the first VAG should refer where relevant. Furthermore, technical VAGs can be expected to refer to the concerns of user-level VAGs directly when examining use cases. The result is naturally a very complex reference graph.

One of the interests of the [[Quality Assurance VAG]] will be to determine the degree of conformance of any aspect of system architecture with the concerns expressed in viewpoints. With a bit of luck we can automate the VAG-walking to yield a nice reference graph as a byproduct of concern traceability checking. That could be visually interesting. :-) 
--[[User:Morgaine Dinova|Morgaine Dinova]] 08:22, 20 October 2007 (PDT)

To put it another way, the fact that there is a wiki reference between two VAGs adds semantic information to the normal web linkage here, and we can use that fact to focus attention on areas that are critical to many viewpoints and which affect the most users. This could be powerful. 
--[[User:Morgaine Dinova|Morgaine Dinova]] 08:52, 20 October 2007 (PDT)
::Why don't we introduce a new concept then, the "cross-cutting issue". A cross-cutting issue would be off limits in terms of creating an explicit VAG for it, but every VAG would be required to examine their output's impact on each cross cutting issue? [[User:Gigs Taggart|Gigs Taggart]] 18:58, 20 October 2007 (PDT)
::* You can't have individual "issues" appearing from thin air, they need justification somewhere. That's why issues are first analyzed thoroughly in end-user VAGs by end-user stakeholders in the context of all the relevant areas simultaneously, which gives them justification, and are then presented as fully baked concerns for other VAGs to take as requirements and constraints. That analysis can't be done in the technical VAGs because those try to focus on one area at a time, whereas end-user VAGs will in almost all cases have concerns that span numerous areas simply because normal user activity usually spans numerous areas. As I explained [[Talk:Viewpoint Advocacy Groups#Viewpoints: the substance behind the concept|further up]], it's fundamental to the viewpoint concept that each set of stakeholders has to define and extract its own [[Architecture_Working_Group_Glossary#Architectural_descriptions_and_views_.28ADV.29|ADV]]s, because this is how the architecture expresses its conformance with their concerns. No other VAG can do that for them, because no other VAG has their scope and concerns. --[[User:Morgaine Dinova|Morgaine Dinova]] 01:03, 21 October 2007 (PDT)
:::*There are some issues that are clearly cross-cutting. Scalability, security, possibly more. These are not things that can be designed in a vacuum. Every group must consider scalability and security issues as their output. You can't just design that stuff in a single subgroup, it's got to be part of everything. [[User:Gigs Taggart|Gigs Taggart]] 07:19, 21 October 2007 (PDT)
::::* Which is precisely why there is a central Scalability VAG, so that everyone who has an interest in scalability (which is almost everybody) can discuss scalability under a well defined terms of references, instead of everyone reinventing it themselves and doing it their own way, badly. You can't expect every VAG to go into scalability in the same depth as the Scalability VAG. You can't expect them all to create tools to describe and to measure scalability. You can't expect them all to know and employ suitable analysis techniques for scalability --- it's a very specialist area. That's why, while almost everybody needs to keep scalability in the back of their minds, the key work is done in the Scalability VAG, and they each take the results of that work back into their own VAGs. It's functional specialization.
::::* And the same applies in reverse. Do you expect people whose special interest and competence and concerns are in Physics Simulation, to duplicate all the work of the REST Services team within the Physics VAG just because they need to be aware of the comms mechanism which underpins services? Of course not. Instead, you expect them to take an interest in the REST Services VAG (or whatever that team calls it) and to import the results of that team into the deliberations of the Physics VAG. It's functional specialization. Likewise the Scalability VAG itself ... we don't intend to duplicate the work of the Physics and REST Services VAGs --- we expect to import the results of their work. Functional specialization.
::::* I really can't understand the basis for an "everyone has to reinvent everything" approach to design. --[[User:Morgaine Dinova|Morgaine Dinova]] 12:21, 21 October 2007 (PDT)

:::::* If I've understood you both, I think there is a question concerning interVAG relations (when VAGs overlap) and subVAGs (special interest group within a subVAG). Organization and comunication of VAGs is important as it affects content of the VAG. As one example of this, a scalability VAG could actually have a facilitor role in helping other VAG address the issue. They might also cover areas where another VAG doen't exist or are unable to handle it.--[[User:Burhop Piccard|Burhop Piccard]] 17:14, 21 October 2007 (PDT)
::::::* That's certainly how I see it, yes. For me, a technical VAG is a project resource. --[[User:Morgaine Dinova|Morgaine Dinova]] 19:45, 21 October 2007 (PDT)

== More groups than participants here ==

* Ok.....this has gotten way out of hand. There are more groups here than participants. Please limit yourself to starting one new VAG per person. Also, I think we should delete VAGs that only have one participant after one month. -- [[User:Rob Linden|Rob Linden]] 10:56, 22 October 2007 (PDT)

* Well.. There's a lot of churn and I think its unclear if all the various groups which have been mentioned are real, or just some people's posting possibilities. I'd much rather sieve groups by results. If one person is passionate about a topic, and getting things done, that's fine with me. That's rather the point of IEEE-1471, that the groupings happen, and should be embraced, not ignored.

Some churn is to be expected, in a project launched with no formal structures in place. Self organizing isn't pretty, but it's what we're doing. -- [[User:Zha Ewry|Zha]] 7:16 PM, 22 October, 2007 (PDT)

Talk:Viewpoint Advocacy Groups

2007-10-23T02:17:21Z

Zha Ewry: Judge by results, churn is expected

AWG: Core simulator exploration

2007-10-22T20:26:11Z

Zha Ewry: Thoughts on core tasks for simulators...

Zha's thoughts on 'the core business of simulators'

'''Raw thoughts warning'''

This is an early draft, of some raw thoughts. Please feel free to
comment on them, ask questions and such. This is not a collective work
product at the moment, but rather an atttempt to share my thinking. I
do think that a more formal, collectively mulled over version of this
page would be a good thing. This isn't it, at least not yet. - [[User:Zha Ewry|Zha]]

This is a companion to my notes on state melding [[AWG: state melding exploration]]. It attempts to explore what the core activities of a region simulator might be, in terms of the rough language of the evolving second generation grid activity being pursued by the AWG. It focuses, as much as possible, not on precise implementation details, but broad, technical approaches, rooted in the AWG's assumptions. It is, again, very much an attempt to get some ideas out and talked about. Feedback, and discussion on this is deeply appreciated and desired.

So, once again, we start with the base terms. We have a region, being hosted in a Region Simulator. This is a second generation deployment, so, the region simulator is only running the simulation. The agent specific portions of activity are assumed to be split off to agent servers running in a separate agent domain, per the proposed design. We will also, for the moment, model scripts slightly oddly, attempting to not make any locality assumptions about where the scripts are run.

The simulator holds:
* A static landscape
* A set of prims:
** Some physical
** Some in linksets
** Some attached to avatars
** Some running scripts
* A set of avatars
** The avatars are coupled to
*** Agents in the agent domain
*** Clients
* A physical simulation program

We start at a given moment, with a ''frame''. The frame is a momentary snapshot of the region, corresponding to the last state all the observers have seen. Our goal is to step forward from the current frame to the next frame, noting what needs to occur as we create the new frame.

We accept a set of sets of inputs: (Some of which may be null sets)
* Motion requests from the clients associated with our avatars
* Chat utterances from the clients associated with our avatars
* Avatar appearance updates
* Changes in the avatar's linksets
* Changes in objects due to scripting inputs
* New objects created in the region due to requests made on the region
* Requests to delete objects due to requests made on the region
* The addition of Avatars
* The subtraction of Avatars

We run a frame of physical simulation. this:
* Moves a set of objects
* Causes some collisions to occur
* May move some objects or avatars out of the region

At this point, we now have a new frame. We now face the challenge of letting all the relevant observers know about the new frame. Each client needs to know, as does every scripted object with a sensor. If we have any viewpoints looking into the region from outside, they too need to be updated.

===What needs to be reported?===

We could just send the entire new frame. But.. In practice, we deeply don't want to do that. What we want, in fact, most likely, is to send all the changes, from each viewpoint's perspective. Roughly, for from each observer's location, out to the distance they observer (The view distance for the clients, the sensing distance for any scripted object) we want to send an update for each changed object

There are several ways to imagine doing this. All revolve around knowing, the location of all the changed objects, the location of all the observation points, and then getting the two together.

Note that this is independent of how we manage the region. We don't yet speak about processes, boundaries and such. A simple approach, tho, is that we have every viewpoint, register a listener on every object inside its observation window, and have the changed objects notify each viewpoint, as they update. As the viewpoint moves (or the size of its observation window changes) we add and delete registrations to the objects accordingly.

=== Running in parallel ===

So, we all say, lets go peer to peer, or run the simulation in parallel...

Does this really help? I'm not sure. Here's why, roughly... We assume each resident is keeping a complete
snapshot of the region they are in. (We ignore for the moment, the cost of getting that to their local machine, or we allocate a grid resource to run the copy for them, and assume we can clone the base region state to the grid resource efficiently) Now, for each frame, (within reason, the looser the constraints, the less shared state we get) Now we distribute the set of inputs to each copy of the region and run the regions in parallel. Since they are running the same algorithms on the same data, we each get similar, ideally identical results. Of course, lost packets, and lag in sharing inputs will rapidly make each copy of the region subtly different. We also have the minor problem of now sharing every avatars inputs, and every scripted object's state changes across all the other copies of the region.

AWG: Core simulator exploration

2007-10-22T20:09:01Z

Zha Ewry: (mid edit)

AW Groupies In-World Meeting Agenda

2007-10-22T19:39:24Z

Zha Ewry:

10-23-2007, 9:30 AM PDT meeting agenda

'''Please add your items here!'''

# Wiki work, building consensus
# VAGs next steps (Actually doing some work)
# Open discussion on state melding (I'll add links, shortly)

AW Groupies In-World Meeting Agenda

2007-10-22T19:38:51Z

Zha Ewry: New page: 10-23-2007, 9:30 AM PDT meeting agenda '''Please add your items here!''' 1) Wiki work, building consensus 2) VAGs next steps (Actually doing some work) 3) Open discussion on state meldin...

10-23-2007, 9:30 AM PDT meeting agenda

'''Please add your items here!'''

1) Wiki work, building consensus
2) VAGs next steps (Actually doing some work)
3) Open discussion on state melding (I'll add links, shortly)

AWG: state melding exploration

2007-10-22T17:51:25Z

Zha Ewry: Personal musings on state melding

Zha's thoughts on 'state melding'

'''Raw thoughts warning'''

This is an early draft, of some raw thoughts. Please feel free to
comment on them, ask questions and such. This is not a collective work
product at the moment, but rather an atttempt to share my thinking. I
do think that a more formal, collectively mulled over version of this
page would be a good thing. This isn't it, at least not yet. - [[User:Zha Ewry|Zha]]

From time to time, I use the phrase state melding, to describe one of the core things which happens in a virtual world. This page is an attempt to describe precisely what I mean by that. It is very
intentionally written so as to avoid, as much as possible, a specific implementation model. There is a companion page [[AWG: Core simulator exploration]] which attempts to capture the actions described on this page, in the context of an architecture based on Linden Lab's second generation grid plans.

The core user experience in a virtual world is that of experiencing the illusion that they are seeing into, and interacting with a virtual world. The virtual world is composed of a base landscape, objects
which exist within the landscape, and avatars. Avatars, represent users, or bots, which are in the same portion of the virtual world.

At the heart of the experience is the notion of a shared reality,
where all the participants appear to be experiencing the same set of
events, in a fashion similar to how people in a space in the real
world experience a consistent reality.

Putting aside notions of philosophy, the core of creating a shared
reality within a portion of a virtual world is melding together the
acions of all the objects, avatars and their interactions into a form
which can be shared among the all of those actors. (And note, it needs to
be shared, not just with the end humans, but with the other objects and
scripts which make up the scene as well. State Melding is about creating
and sharing that melded state.

Consider for a moment, a series of "moments" in a virtual
reagion. (This isn't to assert virtual worlds are, or are not
cotinuous, just so we can talk about the things which get accounted
for, in a stepwise fashion.)

So. At moment one, we have a set of stateful things

* The landscape (hopefully fairly static)
* A set of virtual objects (Note, abstract so not prims, just objects)
* A set of avatars

We take the set of stateful things, and then add a set of inputs which
occur between moments:

* A set of inputs is applied to the objects and avatars
** avatars send motion requests
** avatars send "chat" requests
** avatars update their appearance
* scripts update object properties

* New objects and avatars may be added to the region
** this may include objects attached to avatars
* Old objects and avatars me deleted from the region
** this may include objects attached to avatars

Additionally, any physical simulation applied to the objects
happens. This may include managing motion, friction, collisions,
gravity, and such.

All of these changes coalesce into a new moment. The process by which
this new moment is created, is what I mean by state melding. A whole
set of states and state changes are melded to create a new moment.

Once we have created the new moment, all the interested parties need
to know about it. So, the final step is to, in some way, distribute the new
moment back out to all the concerned parties.

Note: in addition to all of this, there is also the question of things
such as speech and sound, happen, as well as things we are familiar
with, from second life, such as animations, particle systems and
texture animations. These all happen off grid in the SL model, but
some or all of them may in some models happen in world. Not sure how
to account for them, as yet.

User:Zha Ewry

2007-10-22T17:47:55Z

Zha Ewry:

Greetings, I'm an active participant in the [[Architecture Working Group]], an active resident, and an Employee of IBM. This does not not mean, I speak for IBM, except when I very specifically state that I'm doing so. Most of the time, I do not, although clearly my employment affects various of my opinions. If you want to talk to me, I'm in world most of the time, and catch e-mail for SL at zha.ewry@gmail.com.

Participant in [[Architecture Working Group]]. See [[User:Zha Ewry/comments on meeting 1]] for comments on this subject.

=== AWG musings ===

This is a bucket where I toss some ideas I am exploring. Comments deeply appreciated, these are not public consensus pages.

:[[AWG: state melding exploration]]

:[[AWG: Core simulator exploration]]

User:Zha Ewry

2007-10-22T17:42:45Z

Zha Ewry:

Greetings, I'm an active participant in the [[Architecture Working Group]], an active resident, and an Employee of IBM. This does not not mean, I speak for IBM, except when I very specifically state that I'm doing so. Most of the time, I do not, although clearly my employment affects various of my opinions. If you want to talk to me, I'm in world most of the time, and catch e-mail for SL at zha.ewry@gmail.com.

Participant in [[Architecture Working Group]]. See [[User:Zha Ewry/comments on meeting 1]] for comments on this subject.

=== AWG musings ===

This is a bucket where I toss some ideas I am exploring. Comments deeply appreciated, these are not public consensus pages.

[[AWG: state melding exploration]]
[[AWG: Core simulator exploration]]

User talk:Dzonatas Sol/AWG Design Document Template

2007-10-22T05:41:13Z

Zha Ewry: Proposal.. Discuss

* "'''Design Document Template -- ???'''"
:* These pages arose out of refactoring of the AWG Glossary entries, which itself was done without discussion, unilaterally. This was OK in itself since it involved no change in semantics. But now, what used to be simply factored out explanations of glossary terms have been turned into "design documents", and thus the focus of the design process. This runs 100% counter to the concept of viewpoints, which generate the Archtectural Descriptions and Views that describe the architecture. The terms in the glossary certainly can't be the focus of design, since they're all independent whereas design is about composition.

:* "Design Document Template" should be renamed to something else which reflects what they actually are, for example "Term Definition Template". --[[User:Morgaine Dinova|Morgaine Dinova]] 11:43, 21 October 2007 (PDT)

:* I disagree with the glossary being the main focus and the best way to start a design for an architecture. It has already led to generalizations that confuse each one of us. Even if the glossary statements are valid for a term, that does not make them automatically valid for the given model, which Zero presented and Tao further described.

:* Any term being used that does not fall in the scope to describe the given model belongs in the glossary rather than in a design document. The glossary can also hold the names we give to the descriptions of the model. That is where they work together and the wiki makes it easy to refer to each other.

:* If you want, create a Design Document VAG? =) [[User:Dzonatas Sol|Dzonatas Sol]] 12:14, 21 October 2007 (PDT)

* The document here, is being presented as a process.. as a decided way we are doing business. It is, at best a proposal for how to approach the design effort. I have flagged it as such. A discussion, with the many stakeholders involved, leading to a design process, is deeply appropriate here. I also refer the reader to the
[[AWG_Process|Process]] proposal for further thoughts on the process we are taking. I would politely observe that it is a more collegial place for discussion on this topic than a template.

User:Dzonatas Sol/AWG Design Document Template

2007-10-22T05:31:21Z

Zha Ewry: Marked as a proposal

{{:AWG/PageHeader}}

'''These guidelines represent a proposal from a single contributor. The are a fine basis for discussion, but do not represent a consensus or decided perspective on the process the AWG is following. '''

= Guidelines =

* Review [[Design Document Template]] for insight of needed content.

* Design Documents are to describe aspects of the given model. Terminology that is out of scope to describe a specific aspect of the given model belongs in the [[Architecture Working Group Glossary|Glossary]] and does not need its own design document. Rationale: the design documents under this category are specific to the given model. If the title of a design document has the same name of a term that confuses the view, it is best to find a new name for the title of the design document; however, the previous model and the given model both already provide names for aspects of that model, which are commonly used by default for design titles and may confuse the view more if changed. Icons also help to avoid confusion such the icon plus a title can be recognized distinctly from general terminology.

* Title each page with "AWG ''NAMEOFDOC''" where ''NAMEOFDOC'' is the actual name. If possible, upper case only the first letter of each word in ''NAMEOFDOC'', as it is typically done for a title, like "AWG Document Title." The first four characters "AWG " are significant to the macros.

* Start each page with <nowiki>{{:AWG/PageHeader}}</nowiki> in order to transclude the header layout (as shown above) and its macros.

* Avoid generalizations in the Description field. As much as possible, write statements in terms of the now, which means there is an actual model to describe. Also, the use of grammatic infinitives is a bold indication of a generalization (some usage in nouns is unavoidable). Remember, any generalization in design is a bottleneck in implementation.

* Keep the Description field concise but mappable. Use <nowiki>{{AWG|</nowiki>''NAMEOFDOC''<nowiki>}}</nowiki> to map to other AWG design documents. Any specifics beyond basic purpose, terminology, or mappable usage goes in another section (and refer to [[Design Document Template]] for possible sections). The description being mappable to other design documents is a power of the wiki -- use it! (especially to map back to the article itself, for example "A <nowiki>{{AWG|</nowiki>''NAMEOFDOC''<nowiki>}}</nowiki> is ...")

* Upload an icon for the page under the name '''AWG_''NAMEOFDOC''.png''' where ''NAMEOFDOC'' must have underlines instead of spaces. A macro in the pageheader detects the image and inserts it automatically. For now, the icons are sized to 100x100px. Icons are a good means to graphically map the model or indicate states of the model, so it is good to keep them distinct from each other (or redo them to make them more distinct). Don't make icons too complex where it cannot be easily drawn by hand as a conversation piece.

* Use regular wiki sections below the pageheader. For example if there are specifications to list, create a "Specification" section for them.

* Any ''talk'' in the main article is subject to be rewritten to make a formal statement about the design or can be moved to a more appropriate (discussion) page.

= Goals =

* The goal of these AWG Design Documents are to use the abilities of the wiki to create a concise description of interest, with such wikification, in order to express, discuss, and verify a given model being designed. Each article is given workspace for views and viewpoints. The description of interest, being wikified, is navigatible, by its wikicode, to other related design elements. The specifics of each link is tied a each design document in order to augment to consistency of the descriptions with other design documents. Thus, it is possible to verify the given model, and potential any new model, before any implementation because the links avoid generalizations and gives precise directions. Nevertheless, this does not automate the process nor mandates how to write the descriptions, it is provided only to be helpful to both those that design and those that implement the model.

* A secondary goal is to help prevent discussion sprawl. Wikis allow the freedom for discussion to take place on multiple pages, and the intention of the navigational links is to help direct the flow of conversation to the given model. This has already proven to work, but the approach needs refinement to encourage the pull of interest to be less disjoint.

* Also, these design documents provide constructive methods that are useful to visual people, which is positive in accessibility issues.

= Design =

* The guidelines above explain the technique used to make the best of this template. The use of transcluded Description page allows the wikified text (of the description) to be transcluded in other areas of the wiki, which then serves as an informational and navigational instrument.

* '''NOTE:''' If you are familiar with the old MOOs, Zorks, and Adventure style of games, then you will have a perfect example of how the Description should work but with a much more point-n-clickly style of interface instead of keyboarded input to explore! This is comparable to modern S.E.E. tools. (No doubt such environments are based on older Adventure games!)

= Interface Requirements =

* Besides the normal use of a wiki and the guidelines above being followed, the user only has to include the wikicode code transclude the description if that is the only text desired from the design document and its workspace. One example of wikicode to include the above description in the header: <nowiki>{{:AWG/AWG_Design_Document_Template}}</nowiki>

= Performance Requirements =

* Specifics of load on the wiki are not known. In general, transcluded pages are updated in the cache as one page, but it still requires extra access to generate the complete page than a single page with no such inclusions. However, the pull of interest is a factor to consider on the span of documents being edited without any helpful navigation. If these templates are found useful, as useful as the wiki itself is as a template, then the growth of articles is expected to be the same, but that is with the assumption a core of documents with these templates are already done to describe the model.

= Security Impact =

* The description of interest becomes more accessible, and its nature to be transcluded allows for one change to make a wider impact. If abused, a request for augmented security might be needed. However, Wikipedia has shown high tolerance before such preventive measures are of need. If a model becomes final and implemented, it may be reasonable to lock the description pages of the that model and start with fresh new design documents for the next model.

= Community Concerns =

* As the design progresses, parts of the model not yet described may appear broken.

= Support =

* Support is limited to the communication channels available. I've found it costly, so far, but I also have learned how to continue to make progress in the design, which is priceless.

= Limitations =

* The in-line DISPLAYTITLE function of the wiki either is not available or not well documented. There is a special:displaytitle page, but there also exists hints of a wiki magic-word that can be inserted in each page in order to make the title display differently from its URL scheme. I have a hint that such feature may not be fully implemented as of yet due to RESTful desires to keep the title and URL scheme very similar. For now, the URL scheme and display title are similar by such limitation.

= Interactions =

* The use of wikicode with HTML works, but wiki users still are in disagreement if HTML is a feature of a wiki. There is HTML in the template in order to use the CSS styles. The transcluded page and the macros of the template have already replaced much HTML code that have been used in the past in like style.

= Testing =

* The approach of these design documents have been a way to test the test. Besides the progressive design and the appearance of being broken when not fully described, it basically passes that test. =) The subsequent test then becomes a need to continue the design and verify the model. The current progress has already found a flaw in the given model in the same way this may appear broken.

= Deployment =

* Besides a fresh start, continue design of the model here with these design documents!

User talk:Dzonatas Sol/AWG Agent/Description

2007-10-22T04:13:02Z

Zha Ewry: Discuss when you disagree. Edit boldly but with respect

There is clearly a difference of opinion as to the way forward on defining this. Reverting over an edit which included concerns based on the previous edit does not foster discussion. If you do not believe this is the right level of definition for this term, please raise that issue here.