Example 5: Upload video content into a remote DAM server

In this case, the CID server is a Digital Asset Management (DAM) server. This server accepts large contents such as video files. It supports an extra optional step which allows the client to check the authentication and authorization of the user before sending the content.

This example includes a pre-upload interaction step which allows the user to fill platform-specific metadata and a post-upload wait step which is optional and allows the user to monitor the server processing.

Server manifest⚓

1
<?xml version="1.0" encoding="UTF-8"?>
2
<cid:manifest xmlns:cid="http://www.cid-protocol/schema/v1/core" xmlns:xml="http://www.w3.org/XML/1998/namespace" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.cid-protocol/schema/v1/core ../manifest/cid-core.xsd ">
3
    <cid:process is="http://schema.org/SendAction">
4
        <cid:label xml:lang="en">DAM</cid:label>
5
        <cid:meta name="Content-type" is="http://purl.org/dc/elements/1.1/type">
6
            <cid:value>image/png</cid:value>
7
            <cid:value>video/mpeg4</cid:value>
8
        </cid:meta>
9
10
        <cid:meta name="Public-url"  is="http://schema.org/url"/>
11
        <cid:meta name="dc-title" is="http://purl.org/dc/elements/1.1/title"/>
12
        <cid:meta name="dc-creator" is="http://purl.org/dc/elements/1.1/creator"/>
13
        <cid:meta name="dc-modified" is="http://purl.org/dc/terms/modified"/>
14
        <cid:meta name="tags" is="http://schema.org/keywords"/>
15
16
        <!--
17
            An exchange step represents a default HTTP request.
18
19
            In this process, the content to upload could be really large. This first
20
            optional step allows a client to check the authentication and
21
            authorization of a user before sending the content.
22
        -->
23
        <cid:exchange url="http://example.com/checkAuthorization" is="http://schema.org/AuthorizeAction" required="false"/>
24
        <cid:interact url="http://example.com/interact-pre-delivery" useMetas="dc-title dc-creator dc-modified" returnMetas="dc-title dc-creator dc-modified tags" required="true"/>
25
        <!--
26
            An async upload could be used when the post-upload processing need a long
27
            time. After such an upload, the server could return a 202 HTTP code.
28
            A system-oriented wait will then allow the client to send regular exchange
29
            requests to the systemWait URL until it gets a different HTTP code than 202.
30
            A user-oriented wait will then allow the client to instanciate an interact
31
            step at the userWait URL.
32
        -->
33
        <cid:upload url="http://example.com/upload?step=start" needMetas="dc-title dc-creator dc-modified tags" required="true">
34
            <cid:systemWait url="http://example.com/wait?method=system" returnMetas="Public-url"/>
35
            <cid:userWait url="http://example.com/wait?method=user" returnMetas="Public-url"/>
36
        </cid:upload>
37
38
    </cid:process>
39
40
    <cid:transports>
41
        <cid:webTransport sessionProperties="session-ID">
42
            <cid:authentications>
43
                <cid:basicHttp/>
44
                <cid:webAuthentication  url="http://example.com/auth"/>
45
            </cid:authentications>
46
47
            <cid:webExchange>
48
                <cid:request method="GET" properties="header queryString"/>
49
                <cid:request method="POST;application/x-www-form-urlencoded" properties="queryString header post"/>
50
                <cid:request method="POST;multipart/form-data" properties="header queryString post"/>
51
            </cid:webExchange>
52
53
            <cid:webInteract>
54
                <cid:request method="GET" properties="header queryString"/>
55
                <cid:request method="POST;application/x-www-form-urlencoded" properties="queryString header post"/>
56
                <cid:request method="POST;multipart/form-data" properties="header queryString post"/>
57
            </cid:webInteract>
58
59
            <cid:webUpload>
60
                <cid:request method="GET" properties="header queryString"/>
61
                <cid:request method="PUT" properties="header queryString"/>
62
                <cid:request method="POST" properties="queryString header"/>
63
                <cid:request method="POST;multipart/form-data" properties="header queryString post"/>
64
            </cid:webUpload>
65
        </cid:webTransport>
66
    </cid:transports>
67
</cid:manifest>
The process step by step⚓
Procedure
  1. Manifest exposition
    The server must expose the XML manifest to an accessible URL. For example, at http://example.com/manifest.xml.
  2. Download the manifest
    In order to understand the process, a client must download the server manifest and analyze it.
    Download the manifest
  3. Optional exchange
    The client could send a first optional exchange request in order to check the authorization and the authentication of the user. In this case, the client could send an HTTP GET request which contains a basic or digest authentication header.
    Regular exchange
  4. Required interaction
    The first interaction is required. It allows the server to interact directly with the user in order to negotiate the content processing.
    Direct interaction
  5. Upload
    Content upload
    When the server is unable to return the meta properly in the HTTP response, the upload step could define an asynchronous upload. This asynchronous upload step defines wait strategies to let the client get the final meta later. One of these wait strategies must be operated by the client when the upload response of the server contains a HTTP response code 202.
    It is possible to define two wait strategies :
    • A user-oriented wait: the client instantiates a web-frame following the same scheme than an interact step.
    • A system-oriented wait: the client must send regularly an exchange request until the returned HTTP code is different than 202.