Talk:Event Scalability VAG - Revision history

Jesrad Seraph: /* Members (Stakeholders) */

2007-10-25T14:00:38Z

Members (Stakeholders)

← Older revision		Revision as of 07:00, 25 October 2007
Line 17:		Line 17:
	= Members (Stakeholders) =		= Members (Stakeholders) =
	* Hi Jesrad! Glad to see you join here, I was very interested in some of your proposals in Brainstorming, they scaled very well, looked highly promising. And they fitted in well with Zero's agent/region domain split. --[[User:Morgaine Dinova\|Morgaine Dinova]] 13:23, 24 October 2007 (PDT)		* Hi Jesrad! Glad to see you join here, I was very interested in some of your proposals in Brainstorming, they scaled very well, looked highly promising. And they fitted in well with Zero's agent/region domain split. --[[User:Morgaine Dinova\|Morgaine Dinova]] 13:23, 24 October 2007 (PDT)
			:* Thanks :) --[[User:Jesrad Seraph\|Jesrad Seraph]] 07:00, 25 October 2007 (PDT)

	= Scalability for events --- open discussion =		= Scalability for events --- open discussion =

Morgaine Dinova: /* Members (Stakeholders) */

2007-10-24T20:23:25Z

Members (Stakeholders)

← Older revision		Revision as of 13:23, 24 October 2007
Line 16:		Line 16:

	= Members (Stakeholders) =		= Members (Stakeholders) =
			* Hi Jesrad! Glad to see you join here, I was very interested in some of your proposals in Brainstorming, they scaled very well, looked highly promising. And they fitted in well with Zero's agent/region domain split. --[[User:Morgaine Dinova\|Morgaine Dinova]] 13:23, 24 October 2007 (PDT)

	= Scalability for events --- open discussion =		= Scalability for events --- open discussion =

Morgaine Dinova: /* Additional scaling factors */

2007-10-22T09:37:41Z

Additional scaling factors

← Older revision		Revision as of 02:37, 22 October 2007
Line 172:		Line 172:
	Some of the other lines are debateable too ... for example, chat spam isn't a constraint, it's just a reason for increasing the chat falloff rate in crowds. --[[User:Morgaine Dinova\|Morgaine Dinova]] 07:09, 13 October 2007 (PDT)		Some of the other lines are debateable too ... for example, chat spam isn't a constraint, it's just a reason for increasing the chat falloff rate in crowds. --[[User:Morgaine Dinova\|Morgaine Dinova]] 07:09, 13 October 2007 (PDT)
	:I'd say it rather is a reason for tying the chat relay function to something that scales according to the capacity of the client, since the limit to how fast one can keep up with a multi-partied discussion is roughly dependant on how many things happening simultaneously he can keep up with at all, anyway. Now, a mechanism for self setting that limit would be nice. You'll see that my per-resident subdivision proposal handles this quite nicely, by scaling up to the maximum number of concurrent content / avatar sources the client can aggregate. If you're going to not mind, or ignore entirely, the presence of someone or something in particular in a crowded place, might as well save on the load that presence would imply, on both sides. That's the root principle.--[[User:Jesrad Seraph\|Jesrad Seraph]] 07:13, 16 October 2007 (PDT)		:I'd say it rather is a reason for tying the chat relay function to something that scales according to the capacity of the client, since the limit to how fast one can keep up with a multi-partied discussion is roughly dependant on how many things happening simultaneously he can keep up with at all, anyway. Now, a mechanism for self setting that limit would be nice. You'll see that my per-resident subdivision proposal handles this quite nicely, by scaling up to the maximum number of concurrent content / avatar sources the client can aggregate. If you're going to not mind, or ignore entirely, the presence of someone or something in particular in a crowded place, might as well save on the load that presence would imply, on both sides. That's the root principle.--[[User:Jesrad Seraph\|Jesrad Seraph]] 07:13, 16 October 2007 (PDT)
			:* That's an interesting idea. It reminds me of 3D engine discussions, in which I've always held that the normal object-centric approach is inadequate because it cannot scale, whereas an approach centered on client-capability would always scale naturally. In other words, determine a client constraint such as FPS, and then render objects only to the extent permitted by CPU resources available to maintain that constraint, reducing detail, prioritizing and deprioritizing as needed, and collapsing the object space accordingly as it grows. You've effectively said the same thing above, but in the context of world chat. --[[User:Morgaine Dinova\|Morgaine Dinova]] 02:37, 22 October 2007 (PDT)

	= Discussion control =		= Discussion control =

Morgaine Dinova at 09:23, 22 October 2007

2007-10-22T09:23:55Z

← Older revision		Revision as of 02:23, 22 October 2007
Line 1:		Line 1:
	= Purpose =		= Purpose =


	=== Areas addressed by this viewpoint ===		=== Areas addressed by this viewpoint ===


	=== Areas not addressed by this viewpoint ===		=== Areas not addressed by this viewpoint ===
Line 10:		Line 8:

	= Source of Viewpoint =		= Source of Viewpoint =


	= Architectural Descriptions/Views used to express this viewpoint =		= Architectural Descriptions/Views used to express this viewpoint =


	~~= Tools employed by this VAG =~~

	= Tools employed by this VAG =		= Tools employed by this VAG =

	= External Links =		= External Links =


	= Members (Stakeholders) =		= Members (Stakeholders) =

Morgaine Dinova: /* Architectural Descriptions/Views used to express this viewpoint */

2007-10-22T09:22:19Z

Architectural Descriptions/Views used to express this viewpoint

← Older revision		Revision as of 02:22, 22 October 2007
Line 14:		Line 14:
	= Architectural Descriptions/Views used to express this viewpoint =		= Architectural Descriptions/Views used to express this viewpoint =


			= Tools employed by this VAG =

	= Tools employed by this VAG =		= Tools employed by this VAG =

Morgaine Dinova: /* Modeling Techniques used to express viewpoint */

2007-10-22T09:19:14Z

Modeling Techniques used to express viewpoint

← Older revision		Revision as of 02:19, 22 October 2007
Line 12:		Line 12:


	= ~~Modeling Techniques~~ used to express viewpoint =		= Architectural Descriptions/Views used to express this viewpoint =


			= Tools employed by this VAG =

	= External Links =		= External Links =

Morgaine Dinova at 10:22, 19 October 2007

2007-10-19T10:22:03Z

← Older revision		Revision as of 03:22, 19 October 2007
Line 175:		Line 175:
	Some of the other lines are debateable too ... for example, chat spam isn't a constraint, it's just a reason for increasing the chat falloff rate in crowds. --[[User:Morgaine Dinova\|Morgaine Dinova]] 07:09, 13 October 2007 (PDT)		Some of the other lines are debateable too ... for example, chat spam isn't a constraint, it's just a reason for increasing the chat falloff rate in crowds. --[[User:Morgaine Dinova\|Morgaine Dinova]] 07:09, 13 October 2007 (PDT)
	:I'd say it rather is a reason for tying the chat relay function to something that scales according to the capacity of the client, since the limit to how fast one can keep up with a multi-partied discussion is roughly dependant on how many things happening simultaneously he can keep up with at all, anyway. Now, a mechanism for self setting that limit would be nice. You'll see that my per-resident subdivision proposal handles this quite nicely, by scaling up to the maximum number of concurrent content / avatar sources the client can aggregate. If you're going to not mind, or ignore entirely, the presence of someone or something in particular in a crowded place, might as well save on the load that presence would imply, on both sides. That's the root principle.--[[User:Jesrad Seraph\|Jesrad Seraph]] 07:13, 16 October 2007 (PDT)		:I'd say it rather is a reason for tying the chat relay function to something that scales according to the capacity of the client, since the limit to how fast one can keep up with a multi-partied discussion is roughly dependant on how many things happening simultaneously he can keep up with at all, anyway. Now, a mechanism for self setting that limit would be nice. You'll see that my per-resident subdivision proposal handles this quite nicely, by scaling up to the maximum number of concurrent content / avatar sources the client can aggregate. If you're going to not mind, or ignore entirely, the presence of someone or something in particular in a crowded place, might as well save on the load that presence would imply, on both sides. That's the root principle.--[[User:Jesrad Seraph\|Jesrad Seraph]] 07:13, 16 October 2007 (PDT)

			= Discussion control =
			* '''This section created for continuity and openness. It may be removed upon agreement by participants.'''


			Morgaine, please see [[Editing Guidelines]]. We plan to be as inclusive and transparent as a company in our position can, but at the end of the day, we reserve the right to make the final call on any content posted here, and delete as necessary/appropriate. -- [[User:Rob Linden\|Rob Linden]] 10:18, 17 October 2007 (PDT)
			* Thanks for your comments Rob. I spoke to Zero about this issue for the better part of an hour this morning, and I think we have a way of going forward: I'm going to take in all suggested counter-factors which might relieve the pressure on event size, to the best of our estimations, and recalculate. This should bring down the numbers from those strictly proportional to population growth, to lower ones which take other factors into consideration.
			:* In addition, to be more in keeping with the Editing Guidelines as you pointed out, in the next few minutes I'm going to polish away any sharp edges from the comments I wrote here earlier, and most importantly, remove any direct references to participants. We're all working toward the same goals as a team, together, after all. I apologize that my remarks were not consistent with that. :-( --[[User:Morgaine Dinova\|Morgaine Dinova]] 12:32, 17 October 2007 (PDT)
			::* The worst jagged edges now smoothed down. Thanks for comments. :-) --[[User:Morgaine Dinova\|Morgaine Dinova]] 13:17, 17 October 2007 (PDT)

Morgaine Dinova at 10:04, 19 October 2007

2007-10-19T10:04:44Z

Show changes

Morgaine Dinova: New page: = Purpose = === Areas addressed by this viewpoint === === Areas not addressed by this viewpoint === = Event Scalability VAG Glossary = = Source of Viewpoint = = Modeling Techniqu...

2007-10-19T03:12:46Z

New page: = Purpose = === Areas addressed by this viewpoint === === Areas not addressed by this viewpoint === = Event Scalability VAG Glossary = = Source of Viewpoint = = Modeling Techniqu...

New page

= Purpose =

=== Areas addressed by this viewpoint ===

=== Areas not addressed by this viewpoint ===

= Event Scalability VAG Glossary =

= Source of Viewpoint =

= Modeling Techniques used to express viewpoint =

= External Links =

= Members (Stakeholders) =