User:Finrod Meriman/AWG Feedback - Revision history

Finrod Meriman: Blanked the page

2015-02-16T18:42:13Z

Blanked the page

← Older revision		Revision as of 11:42, 16 February 2015
Line 1:		Line 1:
	~~== Some initial reactions to the architecture... ==~~

	'''Disclaimer''': For those who don't know, I work for Intel. Although the comments are generally personal, I am participating in the working group as Intel's representative. I don't speak formally for Intel, but my affiliation certainly influences my position and interests.

	~~=== 1) Architecting the grid is not a once-and-done task. ===~~


	~~In the meeting we discussed two primary motivations. The first is fairly~~
	~~short-term: make it possible to scale performance of the second life~~
	~~grid. The second is more long-term: lay an architectural foundation on~~
	~~which virtual worlds (in general) could scale to millions of users~~
	~~supporting a very diverse set of interactions (everything from WoW to~~
	~~SL). Both motivations are very reasonable. But there is an obvious~~
	~~tension between the two. In the short-term it is necessary to consider~~
	~~the transition from the existing SL Grid though long-term scalability~~
	~~might be best served by a more complete overhaul. It seems pretty~~
	~~obvious that re-architecting the grid needs to be viewed as a multi-step~~
	~~process not a once-and-done event. There will be lots of good ideas to~~
	~~support a fully general, scalable grid that need to be put off for later~~
	~~consideration (or we'll never make progress).~~


	~~=== 2) Make our architectural "views" explicit. ===~~

	~~There is tremendous value in having multiple "views" of an architecture~~
	~~(for those who care, you can look for IEEE 1471 in wikipedia to get an~~
	~~idea how to define views formally). In the meeting I heard three~~
	~~different views presented. The "communication view" described the~~
	~~architecture in terms Certified HTTP using RESTful interactions and~~
	~~LLSD. Most of the detail that was presented focused on the "interface~~
	~~view" or "component view". Each of the agent & region domains were~~
	~~broken into services (with standardized interfaces) based on stateful &~~
	~~stateless interactions. And we discussed a "transactional view" where we~~
	~~hinted at how to sequence the invocation of various services to~~
	~~accomplish a higher level task (eg the login example cascaded through~~
	~~several different invocations... all of which were mandatory to set up~~
	~~the correct state).~~

	~~One view that was missing from the discussion was the "data" or~~
	~~"document" view. What I mean is that we didn't talk about what the data~~
	~~looked like, where it moved around the system, and how the various~~
	~~functions transformed the data. I'm sure some of this will be derived~~
	~~from the current grid architecture, but it still should be thought~~
	~~through & documented. And of course there is the question (for the~~
	~~long-term discussion) as to whether there are other standard 3D object~~
	~~formats that should be adopted to encourage long term stability~~
	~~(e.g. collada, obj, ...).~~

	~~Just a couple more comments on the communication piece... Putting aside~~
	~~my biases about REST... One question I wanted to ask is how the~~
	~~architecture supports caching & replication. How hard would it be to~~
	~~take the appropriate pieces and distribute them through something like~~
	~~Akamai (or some other distributed web cache/content distribution~~
	~~system)? Should the architecture explicitly include a separate CDN to~~
	~~improve performance? This question is, in some sense, a question of both~~
	~~the communication and document views. And it might impact how the~~
	~~services are decomposed.~~


	~~=== 3) We're missing a good functional decomposition. ===~~

	~~Most of the architecture drawings that were presented focused on the~~
	~~separation into region & agent domains. Clearly this is an important~~
	~~separation for enabling multiple administrative domains. However, I~~
	~~think the first structural partitioning should be along functional lines~~
	~~(yes, the agent & region domains already capture an implicit functional~~
	~~breakdown). Just to be concrete... I've been asked the question, by~~
	~~several residents, why IM is so tightly bound to SL. There are many good~~
	~~reasons to bind them (managability for one), but there are also good~~
	~~reasons to separate them. In the case of IM, there are already a number~~
	~~of very good and extensible IM systems such as XMPP (jabber & google~~
	~~talk).~~

	~~A more thorough examination of the functions might help to figure out~~
	~~which services belong in which boxes.~~


	~~=== 4) Managing trust is going to be really hard. ===~~

	~~It appears that transactions/patterns (such as login) involve services~~
	~~in multiple domain. In the case of login, for example, the agent that is~~
	~~created on behalf of a particular user executes services in a region~~
	~~domain where the avatar is located. The agent domain proxies trust for~~
	~~the user potentially across administrative domains. Proxying trust also~~
	~~creates potential problems for tracking/controling where bits are~~
	~~sent. This has impact in managing intellectual property. (Not that the~~
	~~architecture needs to support DRM, but it shouldn't make it impossible~~
	~~to provide some limits on distribution of IP.)~~

Finrod Meriman at 21:13, 13 November 2007

2007-11-13T21:13:13Z

← Older revision		Revision as of 14:13, 13 November 2007
Line 1:		Line 1:
	== Some initial reactions to the architecture... ==		== Some initial reactions to the architecture... ==

	'''Disclaimer''': For those who don't know, I work for Intel. Although the comments are generally personal, I am participating in the working group as Intel's representative. I don't speak formally for Intel, but my affiliation certainly influences my position and interests. ~~[[User:Finrod Meriman/]]~~		'''Disclaimer''': For those who don't know, I work for Intel. Although the comments are generally personal, I am participating in the working group as Intel's representative. I don't speak formally for Intel, but my affiliation certainly influences my position and interests.

	=== 1) Architecting the grid is not a once-and-done task. ===		=== 1) Architecting the grid is not a once-and-done task. ===

Finrod Meriman at 04:54, 11 November 2007

2007-11-11T04:54:50Z

← Older revision		Revision as of 21:54, 10 November 2007
Line 1:		Line 1:
	== Some initial reactions to the architecture... ==		== Some initial reactions to the architecture... ==

	'''Disclaimer''': For those who don't know, I work for Intel. Although the comments are generally personal, I am participating in the working group as Intel's representative. I don't speak formally for Intel, but my affiliation certainly influences my position and interests. [[User:Finrod Meriman]]		'''Disclaimer''': For those who don't know, I work for Intel. Although the comments are generally personal, I am participating in the working group as Intel's representative. I don't speak formally for Intel, but my affiliation certainly influences my position and interests. [[User:Finrod Meriman/]]

	=== 1) Architecting the grid is not a once-and-done task. ===		=== 1) Architecting the grid is not a once-and-done task. ===

Finrod Meriman at 04:54, 11 November 2007

2007-11-11T04:54:10Z

← Older revision		Revision as of 21:54, 10 November 2007
Line 1:		Line 1:

	== Some initial reactions to the architecture... ==		== Some initial reactions to the architecture... ==

	'''Disclaimer''': For those who don't know, I work for Intel. Although the comments are generally personal, I am participating in the working group as Intel's representative. I don't speak formally for Intel, but my affiliation certainly influences my position and interests.		'''Disclaimer''': For those who don't know, I work for Intel. Although the comments are generally personal, I am participating in the working group as Intel's representative. I don't speak formally for Intel, but my affiliation certainly influences my position and interests. [[User:Finrod Meriman]]

	=== 1) Architecting the grid is not a once-and-done task. ===		=== 1) Architecting the grid is not a once-and-done task. ===

Rob Linden: Mic's Feedback moved to User:Finrod Meriman/AWG Feedback: Moving into user space

2007-11-06T22:54:31Z

Mic's Feedback moved to User:Finrod Meriman/AWG Feedback: Moving into user space

← Older revision	Revision as of 15:54, 6 November 2007
(No difference)

Finrod Meriman at 22:38, 25 September 2007

2007-09-25T22:38:43Z

← Older revision		Revision as of 15:38, 25 September 2007
Line 1:		Line 1:
	~~Just some initial reactions to the architecture...~~

			== Some initial reactions to the architecture... ==

	1) Architecting the ~~Grid~~ is not a once-and-done task.		'''Disclaimer''': For those who don't know, I work for Intel. Although the comments are generally personal, I am participating in the working group as Intel's representative. I don't speak formally for Intel, but my affiliation certainly influences my position and interests.

			=== 1) Architecting the grid is not a once-and-done task. ===


	In the meeting we discussed two primary motivations. The first is fairly		In the meeting we discussed two primary motivations. The first is fairly
Line 18:		Line 21:
	consideration (or we'll never make progress).		consideration (or we'll never make progress).

	2) Make our architectural "views" explicit.
			=== 2) Make our architectural "views" explicit. ===

	There is tremendous value in having multiple "views" of an architecture		There is tremendous value in having multiple "views" of an architecture
Line 54:		Line 58:
	services are decomposed.		services are decomposed.

	3) We're missing a good functional decomposition.
			=== 3) We're missing a good functional decomposition. ===

	Most of the architecture drawings that were presented focused on the		Most of the architecture drawings that were presented focused on the
Line 71:		Line 76:
	which services belong in which boxes.		which services belong in which boxes.

	4) Managing trust is going to be really hard.
			=== 4) Managing trust is going to be really hard. ===

	It appears that transactions/patterns (such as login) involve services		It appears that transactions/patterns (such as login) involve services

Finrod Meriman: New page: Just some initial reactions to the architecture... 1) Architecting the Grid is not a once-and-done task. In the meeting we discussed two primary motivations. The first is fairly short-...

2007-09-25T22:33:34Z

New page: Just some initial reactions to the architecture... 1) Architecting the Grid is not a once-and-done task. In the meeting we discussed two primary motivations. The first is fairly short-...

New page

Just some initial reactions to the architecture...

1) Architecting the Grid is not a once-and-done task.

In the meeting we discussed two primary motivations. The first is fairly
short-term: make it possible to scale performance of the second life
grid. The second is more long-term: lay an architectural foundation on
which virtual worlds (in general) could scale to millions of users
supporting a very diverse set of interactions (everything from WoW to
SL). Both motivations are very reasonable. But there is an obvious
tension between the two. In the short-term it is necessary to consider
the transition from the existing SL Grid though long-term scalability
might be best served by a more complete overhaul. It seems pretty
obvious that re-architecting the grid needs to be viewed as a multi-step
process not a once-and-done event. There will be lots of good ideas to
support a fully general, scalable grid that need to be put off for later
consideration (or we'll never make progress).

2) Make our architectural "views" explicit.

There is tremendous value in having multiple "views" of an architecture
(for those who care, you can look for IEEE 1471 in wikipedia to get an
idea how to define views formally). In the meeting I heard three
different views presented. The "communication view" described the
architecture in terms Certified HTTP using RESTful interactions and
LLSD. Most of the detail that was presented focused on the "interface
view" or "component view". Each of the agent & region domains were
broken into services (with standardized interfaces) based on stateful &
stateless interactions. And we discussed a "transactional view" where we
hinted at how to sequence the invocation of various services to
accomplish a higher level task (eg the login example cascaded through
several different invocations... all of which were mandatory to set up
the correct state).

One view that was missing from the discussion was the "data" or
"document" view. What I mean is that we didn't talk about what the data
looked like, where it moved around the system, and how the various
functions transformed the data. I'm sure some of this will be derived
from the current grid architecture, but it still should be thought
through & documented. And of course there is the question (for the
long-term discussion) as to whether there are other standard 3D object
formats that should be adopted to encourage long term stability
(e.g. collada, obj, ...).

Just a couple more comments on the communication piece... Putting aside
my biases about REST... One question I wanted to ask is how the
architecture supports caching & replication. How hard would it be to
take the appropriate pieces and distribute them through something like
Akamai (or some other distributed web cache/content distribution
system)? Should the architecture explicitly include a separate CDN to
improve performance? This question is, in some sense, a question of both
the communication and document views. And it might impact how the
services are decomposed.

3) We're missing a good functional decomposition.

Most of the architecture drawings that were presented focused on the
separation into region & agent domains. Clearly this is an important
separation for enabling multiple administrative domains. However, I
think the first structural partitioning should be along functional lines
(yes, the agent & region domains already capture an implicit functional
breakdown). Just to be concrete... I've been asked the question, by
several residents, why IM is so tightly bound to SL. There are many good
reasons to bind them (managability for one), but there are also good
reasons to separate them. In the case of IM, there are already a number
of very good and extensible IM systems such as XMPP (jabber & google
talk).

A more thorough examination of the functions might help to figure out
which services belong in which boxes.

4) Managing trust is going to be really hard.

It appears that transactions/patterns (such as login) involve services
in multiple domain. In the case of login, for example, the agent that is
created on behalf of a particular user executes services in a region
domain where the avatar is located. The agent domain proxies trust for
the user potentially across administrative domains. Proxying trust also
creates potential problems for tracking/controling where bits are
sent. This has impact in managing intellectual property. (Not that the
architecture needs to support DRM, but it shouldn't make it impossible
to provide some limits on distribution of IP.)