Goto: Documentation Home

Where media has been uploaded to GDS servers, it is often tagged with a unique "Media Keystring", which uniquely identifies that single image (etc). These ids can be used in URLs, but in such a way that you can request them from any GDS server.

Keystring Format

When a Bucket returns a media reference, it returns a coded string value. This string has no intrinsic meaning, it is simply a reference to the media piece. Once you have this "key" string, you can request the media content by forming the URL

/media/key-string [_Image Control Options] [.Type] [?optional-arguments]

This syntax is identical to normal HTTP protocol for requesting images and other media. The server will respond with a suitable media representation for your browser based on the Accept headers in the request. The responses from the server MAY include redirects to another location, but these will generally be transparently handled by browsers. If you are writing direct access clients, you MUST handle all the HTTP redirect status codes

The Url /Media is specifically for dynamic media content such as uploaded logos and photos.

Media keystrings have the following characteristics:

1. They will never be more than 200 bytes (when expressed in UTF8)
2. The will contain only the following characters A..Z, a..z, 0..9 $ _ - ,(comma). They may also contain common diacriticals in the future
3. To be explicit, they will not contain dot, forward or backward slash, space, tab. . / \
4. The underscore character will only be used as a delimiter to seperate image control options (see below), it wont be used as part of a keystring directly.
5. Keystrings are intended to be somehow useful to clients as partial filenames, so will tend to err on the side of safety to assist this goal.

With this simple approach, you can rapidly insert media content in your client applications. However, this technique leaves all control over sizes and types of media to the server and the browser. If you want more control over the media, you need to fetch the metadata for that media resource. The metadata can be retrieved on the URL (...TBS...), which causes the server to respond with an XML packet that may contain one or more of the following fields.

Do not code against this table yet - it is not finalised

Field/Read	Field/Write	DataType	Description
f100	F100_??	??	Target Id.
f101	F		Target Type. See POS MediaFiles table definition for values
f102	F	String	Author. The name of the author of the media when known.
f103	F	String	Attribution text. Literal text that should be displayed where possible citing attribution. For some images and media types use is only permitted where attribution is displayed.
f104	F	String	Comments. Free form comments about the media
f105	F	Number	Copyright type. See POS Mediafiles for codes
f110		Binary data	The binary content of the media. This field is NOT returned to XML clients as XML cannot easily handle the binary data. This field is returned only to binary GNAP clients that specifically request it.
f114	F		Received Date/Time (edt)
f130	F130_E	number	Reserved for Meetu4 for Meetu4 table ids
f131	F131_Q	binary	Reserved for Meetu4 for table primary keys
f132	F132_E	number	Reserved for Meetu4 target table field-ids. Used to have server update record in f131

Keystring Internals

This section is informative only, there is no guarantee operation will continue as described here.

A keystring is construcuted from a series of "Letter" / "Value" blocks. The first two blocks should be "Gnnn" and "Ammm". For example Meetu4 will always generate "G102A213" as a prefix. These values indicate the GDS protocol family 102, and Application 213 (Meetu4)

G	A	Description
102	201	Fieldpine Point Of Sale
102	213	Meetu4
102	214	RetailMAX Customer Link
102	215	RetailMAX (web)

Other Tags. T=Table id from Protocol. D=YYYYmmddHHMMSS Z=uniqueid F=basefile (applications choose meaning) O=offset