Talk:AssetServer - Revision history

Serendipity: /* Why Not Real UUID? */

2011-03-21T05:46:56Z

‎Why Not Real UUID?

Serendipity: /* Metadata */

2010-02-13T09:15:31Z

‎Metadata

Mark.malewski: Talk:AssetServerProposal moved to Talk:AssetServer: Although this document/proposal is a work in progress, I have moved it to the "AssetServer" location. Please continue to work on updating this page, and work on any final changes and remote the

2009-05-21T10:06:12Z

Talk:AssetServerProposal moved to Talk:AssetServer: Although this document/proposal is a work in progress, I have moved it to the "AssetServer" location. Please continue to work on updating this page, and work on any final changes and remote the

Awebb: /* Other Comments */

2008-10-09T15:16:47Z

‎Other Comments

Awebb: New section: Other Comments

2008-10-09T15:16:29Z

New section: Other Comments

Awebb: /* Examples */

2008-10-09T15:12:35Z

‎Examples

Awebb: New section: Examples

2008-10-09T15:12:22Z

New section: Examples

Awebb: /* Is the answer "both"? */

2008-10-09T14:43:16Z

‎Is the answer "both"?

Awebb: /* Existing Technologies */

2008-10-09T14:29:03Z

‎Existing Technologies

Awebb: /* Existing Technologies */

2008-10-09T14:28:06Z

‎Existing Technologies

@@ Line 22: / Line 22: @@
 = Why Not Real UUID? =
-A 128 bit identifier is quite capable of being a truly universal identifier.  So why say that an identifier is only valid or meaningful in the context of a particular grid?   Does this mean that it is only unique there or simply that it only corresponds to anything on one grid?   I would have to presume the latter as the former would be unnecessarily restrictive.    So to get the second to work in that an identifier always can be used to find/retrieve objects is a sort of distributed dictionary problem.  Alternately it can be seen as simply a multicast request for some grid to own up to having the object and optionally send it along for replication.   This in turn opens up the need to broadcast minimal change set information so that holders of a replicant know they are out of date.  The simplest changeset is simply the list of ids for modified objects.   All grids other than the sender that have a replica toss it if the message specifies a newer time for that id.  On next use the object will be refetched from the then current freshes copy.  This elides several points but is definitely doable.
+A 128 bit identifier is quite capable of being a truly universal identifier.  So why say that an identifier is only valid or meaningful in the context of a particular grid?  Having it be restricted like that is against the really lovely desire to have asset servers be independent of particular grids. Does this mean that it is only unique there or simply that it only corresponds to anything on one grid?   I would have to presume the latter as the former would be unnecessarily restrictive.    So to get the second to work in that an identifier always can be used to find/retrieve objects is a sort of distributed dictionary problem.  Alternately it can be seen as simply a multicast request for some grid to own up to having the object and optionally send it along for replication.   This in turn opens up the need to broadcast minimal change set information so that holders of a replicant know they are out of date.  The simplest changeset is simply the list of ids for modified objects.   All grids other than the sender that have a replica toss it if the message specifies a newer time for that id.  On next use the object will be refetched from the then current freshes copy.  This elides several points but is definitely doable.
 --[[User Serendipity|Serendipity]]

@@ Line 13: / Line 13: @@
 NOTE: I am suggesting the use of an XML schema as the reference specification; I am not mandating XML as the transport metadata (though that would be an easy way to go).
-Strong typing does seem like it limits the underlying serialization model though. I think we cannot lose sight of the fact that weak typing is fine for communication between closely coupled serialisers/deserialisers (such as .NET provides); in such a case the context is relied upon to restore the type information lost during the intermediate transformation.
+Strong typing does seem like it limits the underlying serialization model though. I think we cannot lose sight of the fact that
 So, summarizing my jumbled thoughts: I think we need a strongly typed specification that can be used in conjunction with the weakly-typed serialization languages to ensure that crtiical type information is not lost along the way. Some kind of self-defining data approach that allows us to package type information separately to the data (this is still sounding like XML to me). By separating the two, type information could be transmitted once, cached by the user, and combined with inbound data by a the deserializer. I'm hoping this Wiki page really does have limited visiblity, because it sounds like there could be some IP in such an approach. Ultimately, the point is that in a simple loosely typed system you cannot 'rediscover' type information, and in a strongly-typed system you can be hamstrung by it. But in a system that separates the two, you can use it if you want, and ignore it (or subvert it) as you choose.
 --[[User:Awebb|Awebb]] 06:58, 9 October 2008 (PDT)
 = Not Just Serving : Asset Catalogs =

@@ Line 39: / Line 39: @@
 --[[User:Awebb|Awebb]] 08:12, 9 October 2008 (PDT)
-== Other Comments ==
+= Other Comments =
 I think it is important to separate the definition of an asset server, what it does, and what it communicates, from the specific mechanisms that will be employed. REST, XMLRPC, are all feasible, but I think it is very important that there be a recognizable interface between these notions. Like typing, protocols will come and go, the asset server's architecture should not be transport specific, or worse, transport dependent.

← Older revision		Revision as of 15:16, 9 October 2008
Line 38:		Line 38:
	it will be great if we can demonstrate effective and proper use of the existing HTTP control mechanisms. For example, use 'Allow' to indicate the methods supported for a resource, or the media range capabilities of "Accept" to communicate desired quality/bandwidth etc..		it will be great if we can demonstrate effective and proper use of the existing HTTP control mechanisms. For example, use 'Allow' to indicate the methods supported for a resource, or the media range capabilities of "Accept" to communicate desired quality/bandwidth etc..
	--[[User:Awebb\|Awebb]] 08:12, 9 October 2008 (PDT)		--[[User:Awebb\|Awebb]] 08:12, 9 October 2008 (PDT)
		+
		+	== Other Comments ==
		+
		+	I think it is important to separate the definition of an asset server, what it does, and what it communicates, from the specific mechanisms that will be employed. REST, XMLRPC, are all feasible, but I think it is very important that there be a recognizable interface between these notions. Like typing, protocols will come and go, the asset server's architecture should not be transport specific, or worse, transport dependent.

@@ Line 34: / Line 34: @@
 --[[User:Awebb|Awebb]] 07:28, 9 October 2008 (PDT)
-== Examples ==
+= Examples =
 it will be great if we can demonstrate effective and proper use of the existing HTTP control mechanisms. For example, use 'Allow' to indicate the methods supported for a resource, or the media range capabilities of "Accept" to communicate desired quality/bandwidth etc..
 --[[User:Awebb|Awebb]] 08:12, 9 October 2008 (PDT)

← Older revision		Revision as of 15:12, 9 October 2008
Line 33:		Line 33:
	Could you be a little more specific? There are a lot of technologies out there. The sooner we get specific about what is going to be used, the sooner people can cry foul. As it is everyone will just tend to assume their own preferred approach and say nothing.		Could you be a little more specific? There are a lot of technologies out there. The sooner we get specific about what is going to be used, the sooner people can cry foul. As it is everyone will just tend to assume their own preferred approach and say nothing.
	--[[User:Awebb\|Awebb]] 07:28, 9 October 2008 (PDT)		--[[User:Awebb\|Awebb]] 07:28, 9 October 2008 (PDT)
		+
		+	== Examples ==
		+
		+	it will be great if we can demonstrate effective and proper use of the existing HTTP control mechanisms. For example, use 'Allow' to indicate the methods supported for a resource, or the media range capabilities of "Accept" to communicate desired quality/bandwidth etc..
		+	--[[User:Awebb\|Awebb]] 08:12, 9 October 2008 (PDT)

@@ Line 7: / Line 7: @@
 == Is the answer "both"? ==
-I have always felt that the notion of an XML schema allows us to have the best of both worlds; provided we couple it with an understandable versioning scheme. I think strong typing is very desirable from the point of view predictable behavior, but for something like this there is clearly NOT going to be a stable data model over its lifetime regardless of how well the initial model is thought out. I totally agree re: supporting any preferred format for serialization; that should be something agreed between the session partners.
+I have always felt that the notion of an XML schema allows us to have the best of both worlds; provided we couple it with an understandable versioning scheme. I think strong typing is very desirable from the point of view predictable behavior, but for something like this there is clearly NOT going to be a stable data model over its lifetime regardless of how well the initial model is thought out.
 --[[User:Awebb|Awebb]] 06:58, 9 October 2008 (PDT)

@@ Line 20: / Line 20: @@
 --[[User:Awebb|Awebb]] 07:20, 9 October 2008 (PDT)
-= Existing Technologies =
+= Leveraging Existing Infrastructure & Scalability =
 Could you be a little more specific? There are a lot of technologies out there. The sooner we get specific about what is going to be used, the sooner people can cry foul. As it is everyone will just tend to assume their own preferred approach and say nothing.
 --[[User:Awebb|Awebb]] 07:28, 9 October 2008 (PDT)