GDS Media Access

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/ReadField/WriteDataTypeDescription
f100F100_????Target Id.
f101FTarget Type. See POS MediaFiles table definition for values
f102FStringAuthor. The name of the author of the media when known.
f103FStringAttribution 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.
f104FStringComments. Free form comments about the media
f105FNumberCopyright type. See POS Mediafiles for codes
f110Binary dataThe 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.
f114FReceived Date/Time (edt)
f130F130_EnumberReserved for Meetu4 for Meetu4 table ids
f131F131_QbinaryReserved for Meetu4 for table primary keys
f132F132_EnumberReserved 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)

GADescription
102201Fieldpine Point Of Sale
102213Meetu4
102214RetailMAX Customer Link
102215RetailMAX (web)

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