Metadata

As far as the specific serialization format goes I don't have much of a preference. Ideally, a robust asset server would support multiple serialization formats such as XML, LLSD XML, JSON, binary, etc. Where it gets tricky is with the higher level representation. There are two schools of thought: strongly typed data and weakly typed data. Linden Lab's UDP, Google's Protocol Buffers, and Facebook's Thrift are examples of strongly typed protocols. Linden Lab's structured data and most XML schemas are examples of weakly typed data.

Should systems like the asset service focus on strongly or weakly typed data? Are there compelling reasons to choose one direction over the other? --Jhurliman 15:59, 6 October 2008 (PDT)

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.

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.

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.

--Awebb 06:58, 9 October 2008 (PDT)

Not Just Serving : Asset Catalogs

The focus of the page is upon retrieval of a previously identified asset, i.e. some VW entity already contains a reference to the asset. But how are the assets initially selected? I think a key part of an asset server is going to be the cataloging mechanism that allows users (customers) to locate the assets they want for a particular purpose. This could be a very nice and interesting subsidiary project maybe. This represents an entirely separate metadata domain, being metadata that is not normally shared with the client. In practice, it may ultimately be the principal differentiator between asset server offerings. --Awebb 07:06, 9 October 2008 (PDT)

Authentication

I don't find the authentication proposal convincing (but then nothing is obvious to the uninformed). I really like the idea of capabilities as cookies, that seems entirely more palatable than (ab)using the URI in the fashion suggested elsewhere, but can we elaborate on this at least to the extent that its sufficiency and scalability are more apparent to the reader? Bear in mind I'm looking at this from a REST point of view, so there is no worthwhile notion of a session that can be exploited in an efficient manner here. Is there? --Awebb 07:20, 9 October 2008 (PDT)

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. --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.. --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. --Awebb 08:16, 9 October 2008 (PDT)