Asset Wrapper
Revision as of 11:42, 17 April 2007 by Phoenix Linden (talk | contribs)
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.
| Reference | extension | id | mime type | LSL |
|---|---|---|---|---|
| Asset Wrapper | asset | unassigned | application/vnd.ll.asset |
Requirements
A simple container format has been invented to wrap assets in a somewhat flexible and concise manner. Specifically we needed a format which:
- provides features for attribution.
- the meta-data needs to be in the first network packet. (specifically a requirement of texture attribution)
- supports arbitrary meta-data.
- introduces minimal byte overhead and does not require increased payload size.
Other container formats were considered but rejected for one of:
- too much overhead
- poor cross-language and cross-platform support
- geared for streaming content rather than fixed assets.
Specification
The asset type is an LLSD array of arrays. Each sub-array will contain a LLSD map of meta-data followed by the data segment. Asset files are serialized in binary LLSD unless a header in asset file indicates otherwise.
The asset file:
- must be an array of arrays.
- should be binary
- may not have a header to indicate binary serialization
- must indicate if they are not serialized in the binary format in the first line of the file.
- should not contain more than one segment of a particular content-type.
The meta-data segment:
- must contain the 'content-type' of the data.
- should contain a 'creation-date' of the data.
- should not contain a 'content-length'.
This is a notation based mock-up of what an asset will actually look like:
[[{'content-type':'image/x-j2c',
'creation-date':'2007-01-01T00:01:00Z',
'creator-id':u3c115e51-04f4-523c-9fa6-98aff1034730},
<BINARY IMAGE DATA>]]