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.
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:
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
|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|
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)
|102||201||Fieldpine Point Of Sale|
|102||214||RetailMAX Customer Link|
Other Tags. T=Table id from Protocol. D=YYYYmmddHHMMSS Z=uniqueid F=basefile (applications choose meaning) O=offset