Talk:Second Life Grid Glossary

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.

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.

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. --Morgaine Dinova 09:29, 25 September 2007 (PDT)

• Added Services and Utilities to the list -- 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.--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? --Morgaine Dinova 02:32, 12 October 2007 (PDT)

• did that. refactored page into IEEE 1471 page and glossary page while i was at it. Dr Scofield 09:12, 12 October 2007 (PDT)

• Thanks, that's hugely better. :-) --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 --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 ADVs 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. - 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. :-) --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. --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. --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. --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 minimal template and add a detailed template? --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. --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. :-) --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? --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. -Zha 7:59 pm PDT, October 17, 2007