User talk:Burhop Piccard/Geometry Based Architecture View - Revision history

Burhop Piccard: /* AWG or not AWG */

2007-11-08T14:52:59Z

AWG or not AWG

← Older revision		Revision as of 07:52, 8 November 2007
Line 37:		Line 37:
	==AWG or not AWG==		==AWG or not AWG==
	: For now, I've backed out Liana's removal of the AWG reference. There was about 40 minutes of discussion on this topic at Zero's office on 11-6-07 (right after Zero left) so it still seems relevent. We can remove it later once everyone agrees it is outside scope. Right now, parts still seem debatable. --[[User:Burhop Piccard\|Burhop Piccard]] 08:08, 7 November 2007 (PST)		: For now, I've backed out Liana's removal of the AWG reference. There was about 40 minutes of discussion on this topic at Zero's office on 11-6-07 (right after Zero left) so it still seems relevent. We can remove it later once everyone agrees it is outside scope. Right now, parts still seem debatable. --[[User:Burhop Piccard\|Burhop Piccard]] 08:08, 7 November 2007 (PST)

			: Took it back out given the discussion on SLDEV. Hey, I'm flexible when it comes to logical arguments :-) --[[User:Burhop Piccard\|Burhop Piccard]] 06:52, 8 November 2007 (PST)

Burhop Piccard: AWG or not AWG

2007-11-07T16:08:44Z

AWG or not AWG

← Older revision		Revision as of 09:08, 7 November 2007
Line 34:		Line 34:
	: Notice that this leaves only the comms front end as the fixed portion of the client, which is as it should be given our plans for very wide client diversity.		: Notice that this leaves only the comms front end as the fixed portion of the client, which is as it should be given our plans for very wide client diversity.
	: I hope this explains my remarks under "Overview" better. :-) --[[User:Morgaine Dinova\|Morgaine Dinova]] 14:55, 4 November 2007 (PST)		: I hope this explains my remarks under "Overview" better. :-) --[[User:Morgaine Dinova\|Morgaine Dinova]] 14:55, 4 November 2007 (PST)

			==AWG or not AWG==
			: For now, I've backed out Liana's removal of the AWG reference. There was about 40 minutes of discussion on this topic at Zero's office on 11-6-07 (right after Zero left) so it still seems relevent. We can remove it later once everyone agrees it is outside scope. Right now, parts still seem debatable. --[[User:Burhop Piccard\|Burhop Piccard]] 08:08, 7 November 2007 (PST)

Liana Linden: Talk:Geometry Based Architecture View moved to User talk:Burhop Piccard/Geometry Based Architecture View: AWG wiki restructuring edit

2007-11-06T23:21:30Z

Talk:Geometry Based Architecture View moved to User talk:Burhop Piccard/Geometry Based Architecture View: AWG wiki restructuring edit

← Older revision	Revision as of 16:21, 6 November 2007
(No difference)

Morgaine Dinova: /* Communication */

2007-11-05T10:21:00Z

Communication

← Older revision		Revision as of 03:21, 5 November 2007
Line 21:		Line 21:
	* ''QUOTE: "Third party applications wanting to upload data to an asset server would value thoughput over latency and granularity. ... Communication with the viewer requires minimum latency and greater control of the input stream."''		* ''QUOTE: "Third party applications wanting to upload data to an asset server would value thoughput over latency and granularity. ... Communication with the viewer requires minimum latency and greater control of the input stream."''
	:: I think we can safely assume that we'll have both comms optimizations available, to use as required. Even a simple dual high+low priority streams approach would give us much of the flexibility needed in this area. Nobody has started off a Communications VAG yet (I hesitate to start it myself :P), but this kind of requirement will certainly need to be captured somewhere, and the Geometry/Physics VAG isn't the right place for it, except as a use case. --[[User:Morgaine Dinova\|Morgaine Dinova]] 13:47, 4 November 2007 (PST)		:: I think we can safely assume that we'll have both comms optimizations available, to use as required. Even a simple dual high+low priority streams approach would give us much of the flexibility needed in this area. Nobody has started off a Communications VAG yet (I hesitate to start it myself :P), but this kind of requirement will certainly need to be captured somewhere, and the Geometry/Physics VAG isn't the right place for it, except as a use case. --[[User:Morgaine Dinova\|Morgaine Dinova]] 13:47, 4 November 2007 (PST)

			* I'm actually wondering why data is uploaded to servers in the Agent Domain at all in the diagram, since this data is in transit to asset storage and doesn't get instantiated as in-world objects until either Agent or Region domain servers pull it in from asset storage. In other words, uploads are unnecessarily traversing the Agent Domain and reducing its ability to scale.
			:: Although the loading created by data uploads will not be large, the loading on Agent Domain servers from normal agent duties will be extreme, and therefore any additional loading is a very bad idea. Whatever processing ''can'' be removed from Agent Domain servers, ''should'' be removed. In this particular case, what's needed is a new server pool of data upload or asset proxies --- in keeping with the "Domain" terminology, this pool might as well be labelled '''Asset Domain''' or similar. --[[User:Morgaine Dinova\|Morgaine Dinova]] 02:21, 5 November 2007 (PST)

	== Components ==		== Components ==

Morgaine Dinova: /* Components */

2007-11-04T23:08:00Z

Components

← Older revision		Revision as of 16:08, 4 November 2007
Line 30:		Line 30:

	: Notice that this leaves only the comms front end as the fixed portion of the client, which is as it should be given our plans for very wide client diversity.		: Notice that this leaves only the comms front end as the fixed portion of the client, which is as it should be given our plans for very wide client diversity.
	: I hope this explains my remarks under "~~Communication~~" better. :-) --[[User:Morgaine Dinova\|Morgaine Dinova]] 14:55, 4 November 2007 (PST)		: I hope this explains my remarks under "Overview" better. :-) --[[User:Morgaine Dinova\|Morgaine Dinova]] 14:55, 4 November 2007 (PST)

Morgaine Dinova: /* Components */

2007-11-04T23:07:01Z

Components

← Older revision		Revision as of 16:07, 4 November 2007
Line 23:		Line 23:

	== Components ==		== Components ==
	* I'll explain what I wrote in the ~~previous~~ section ~~here~~, as you've elaborated on it under "Components".		* I'll explain what I wrote in the "Overview" section about the diagram, as you've elaborated on it under "Components".

	: Your two renderers Fand G and the special application E need to plug in somewhere to what you label the "viewer", but think about this for a minute. Is it really the old viewer, with a superficial external interface, or does the nature of E/F/G require deep coupling into the inner recesses of the client? There is no doubt that it is the latter case, because renderers are necessarily very deeply integrated into the client's rendering susbsystem, and because tools like app E deal with object representation, and therefore must necessarily pass low level data across the interface.		: Your two renderers Fand G and the special application E need to plug in somewhere to what you label the "viewer", but think about this for a minute. Is it really the old viewer, with a superficial external interface, or does the nature of E/F/G require deep coupling into the inner recesses of the client? There is no doubt that it is the latter case, because renderers are necessarily very deeply integrated into the client's rendering susbsystem, and because tools like app E deal with object representation, and therefore must necessarily pass low level data across the interface.

Morgaine Dinova: /* Communication */

2007-11-04T23:05:54Z

Communication

← Older revision		Revision as of 16:05, 4 November 2007
Line 14:		Line 14:

	[[User:Burhop Piccard\|Burhop Piccard]] 15:21, 3 November 2007 (PDT)		[[User:Burhop Piccard\|Burhop Piccard]] 15:21, 3 November 2007 (PDT)

			== Overview ==
			* I suggest that you label the brown box not "Viewer", but "Comms Mux/Demux" or "Client Front-end" or something like that. The old term "Viewer" or "Client" needs to become an outer dotted line that encloses all 4 of your client-side boxes, after the refactoring that's implicit in your article. --[[User:Morgaine Dinova\|Morgaine Dinova]] 15:05, 4 November 2007 (PST)

	== Communication ==		== Communication ==

	* ''QUOTE: "Third party applications wanting to upload data to an asset server would value thoughput over latency and granularity. ... Communication with the viewer requires minimum latency and greater control of the input stream."''		* ''QUOTE: "Third party applications wanting to upload data to an asset server would value thoughput over latency and granularity. ... Communication with the viewer requires minimum latency and greater control of the input stream."''
	::* I think we can safely assume that we'll have both comms optimizations available, to use as required. Even a simple dual high+low priority streams approach would give us much of the flexibility needed in this area. Nobody has started off a Communications VAG yet (I hesitate to start it myself :P), but this kind of requirement will certainly need to be captured somewhere, and the Geometry/Physics VAG isn't the right place for it, except as a use case. --[[User:Morgaine Dinova\|Morgaine Dinova]] 13:47, 4 November 2007 (PST)		:: I think we can safely assume that we'll have both comms optimizations available, to use as required. Even a simple dual high+low priority streams approach would give us much of the flexibility needed in this area. Nobody has started off a Communications VAG yet (I hesitate to start it myself :P), but this kind of requirement will certainly need to be captured somewhere, and the Geometry/Physics VAG isn't the right place for it, except as a use case. --[[User:Morgaine Dinova\|Morgaine Dinova]] 13:47, 4 November 2007 (PST)

	== Components ==		== Components ==

Morgaine Dinova: /* Communication */

2007-11-04T22:55:21Z

Communication

← Older revision		Revision as of 15:55, 4 November 2007
Line 19:		Line 19:
	* ''QUOTE: "Third party applications wanting to upload data to an asset server would value thoughput over latency and granularity. ... Communication with the viewer requires minimum latency and greater control of the input stream."''		* ''QUOTE: "Third party applications wanting to upload data to an asset server would value thoughput over latency and granularity. ... Communication with the viewer requires minimum latency and greater control of the input stream."''
	::* I think we can safely assume that we'll have both comms optimizations available, to use as required. Even a simple dual high+low priority streams approach would give us much of the flexibility needed in this area. Nobody has started off a Communications VAG yet (I hesitate to start it myself :P), but this kind of requirement will certainly need to be captured somewhere, and the Geometry/Physics VAG isn't the right place for it, except as a use case. --[[User:Morgaine Dinova\|Morgaine Dinova]] 13:47, 4 November 2007 (PST)		::* I think we can safely assume that we'll have both comms optimizations available, to use as required. Even a simple dual high+low priority streams approach would give us much of the flexibility needed in this area. Nobody has started off a Communications VAG yet (I hesitate to start it myself :P), but this kind of requirement will certainly need to be captured somewhere, and the Geometry/Physics VAG isn't the right place for it, except as a use case. --[[User:Morgaine Dinova\|Morgaine Dinova]] 13:47, 4 November 2007 (PST)

			== Components ==
			* I'll explain what I wrote in the previous section here, as you've elaborated on it under "Components".

			: Your two renderers Fand G and the special application E need to plug in somewhere to what you label the "viewer", but think about this for a minute. Is it really the old viewer, with a superficial external interface, or does the nature of E/F/G require deep coupling into the inner recesses of the client? There is no doubt that it is the latter case, because renderers are necessarily very deeply integrated into the client's rendering susbsystem, and because tools like app E deal with object representation, and therefore must necessarily pass low level data across the interface.

			: What this means then is that the client must have been ''refactored'' first in order to provide the strong integration capability that you require for advanced geometry. But, if it's been refactored, then it would make very little sense to keep the rest of the client from benefitting from that refactoring, for instance by making the existing prim types also defined through plugins plus corresponding renderers, and indeed by making the whole UI structured as plugins as well, and the audio player, etc.

			: Notice that this leaves only the comms front end as the fixed portion of the client, which is as it should be given our plans for very wide client diversity.
			: I hope this explains my remarks under "Communication" better. :-) --[[User:Morgaine Dinova\|Morgaine Dinova]] 14:55, 4 November 2007 (PST)

Morgaine Dinova at 21:47, 4 November 2007

2007-11-04T21:47:50Z

← Older revision		Revision as of 14:47, 4 November 2007
Line 14:		Line 14:

	[[User:Burhop Piccard\|Burhop Piccard]] 15:21, 3 November 2007 (PDT)		[[User:Burhop Piccard\|Burhop Piccard]] 15:21, 3 November 2007 (PDT)

			== Communication ==

			* ''QUOTE: "Third party applications wanting to upload data to an asset server would value thoughput over latency and granularity. ... Communication with the viewer requires minimum latency and greater control of the input stream."''
			::* I think we can safely assume that we'll have both comms optimizations available, to use as required. Even a simple dual high+low priority streams approach would give us much of the flexibility needed in this area. Nobody has started off a Communications VAG yet (I hesitate to start it myself :P), but this kind of requirement will certainly need to be captured somewhere, and the Geometry/Physics VAG isn't the right place for it, except as a use case. --[[User:Morgaine Dinova\|Morgaine Dinova]] 13:47, 4 November 2007 (PST)

Burhop Piccard at 22:55, 3 November 2007

2007-11-03T22:55:51Z

← Older revision		Revision as of 15:55, 3 November 2007
Line 13:		Line 13:
	* More explicit link between non-SL data stored on the Agent domain and the Viewer. Data in Format F or G must have an equivilent F or G Renderer in the Viewer		* More explicit link between non-SL data stored on the Agent domain and the Viewer. Data in Format F or G must have an equivilent F or G Renderer in the Viewer

	--[[User:Burhop Piccard\|Burhop Piccard]] 15:21, 3 November 2007 (PDT)		[[User:Burhop Piccard\|Burhop Piccard]] 15:21, 3 November 2007 (PDT)