Meeting Notes 2018 06 27

Meeting Notes June 27, 2018

We should add a section describing how the player should load the iframe

We should specify how the iframe overlays (should overlay entire player)

The player should be responsible for attaching the iframe to the DOM

The player shouldn’t include CSS that prevents the iframe from loading. (make this general as browsers might change)

Starting the iframe might not be the original size.

There should be communication about what the actual size should be (it would be ideal to have this available on initialization)

Player may decide to preload ad in iframe that is not visible.

The first message that should come should be the creative handshake message from the Ad. No messages should be posted to the iframe before this.

To be determined: Should we have any parameters on the URL query

We need to list attributes the iframe should and should not have (border, css, fullscreen)

We should recommend that the iframe is cross domain. Specify in the spec that the player should be prepared for cross domain.

Specify sequence

• player creates iframe
• player starts listening for messages
• player adds src element

We need to define the transport layer

o transport (how are messages relayed)

§ we need to specify postmessage (need to specify which frame postmessage goes to)

Player should begin listening immediately (perhaps this should be in loading the iframe section)

protocol (the format of the messages)

§ Define that the argument should be json encoded

Define how a random number session ID should be generated

{ sessionId :”random number”, /// required type : ”name”, // required

messageId: “incremented number”, //required

args : {arg1: “value” arg2: ”value” } // required (could be empty, specify it is object not array) } ·
·
Naming guidelines: Use camel case, · use booleans instead of 1 and 0, All arguments should stringafiable ·
Should response be required or optional. ·

We need to determine what postmessage calls should be mandatory (keeping a simple use case in mind)

How about errors (have a defined interface for errors)

o

include optional stack trace field error code

Does it make sense to have a separate spec to describe the transport layer

Lets set some specific goals for the next two meetings

Lets break of tasks into sections and have some things to discuss for the next 2 meetings (for example person 1 write section A first draft ... etc.)

Other Meeting notes:

There was a suggestion that a good interface could port over to Roku

There was a discussion around mobile apps. The consensus was that this should work.

What about creatives that aren’t interested in messages (like an overlay)?

There should be no problem with preloading into hidden iframes.

How about using the query string to pass some initial information (like expected size)

Url length should be fine

If you use hash, you would need to wait to load javascript regardless

Could there be a problem with missing the first message because of script not loaded?

There is discussion around how to get the player to preload ad assets ·
Is this possible with prerolls?

How about adding macros to the SIVIC URL We need to decide where messages are posted to (iframe window or parent window)

Decision is that ad posts to parent window, player posts to ad window

How about having a protocol defined on the json message (like define it as SIVIC)

There was a suggestion as to whether the transport layer should respond to all messages

One argument for it, is that it simplifies the protocol, having a single type of interface

Adds some error handling ability

preforms operations and indicates completion

ACTION ITEMS

• Iframe loading - Ryan to create (issue or pull request)
• It might make sense to write a sample Protocol transport layer - Pieter & Tim to write first draft (as a separate document within the SIVIC directory)
• Suggestion from Andre - Why not have the player listen for postmessage on the content window. Andrei to see if this is possible. Make a small sample to see if this works.