oliver engine

[kristopolous]

We can use our existing engine, this would be running inside it - whether as some iframe or say some "plugin" to the existing engine is tbd.

[kristopolous]

we're going to for now assume no oversubscription so no mitigation of deciding between ads for an area.

Instead we'll use distances to represent some magnitude and then use that as a threshold to determine whether to put an ad in a "rotation" that we'll be giving.

In a way, the mechanics of cycling through "campaigns" of "assets" doesn't change ... just the labels ... we are cycling through "topics" of "posts" and after finishing a "topic" we can send off our location and get updates ... in the same way we do now.

[kristopolous]

this means that really the sow systems which returned a list of campaigns to choose from doesn't really change - just the screen's way of going about the choosing.

This doesn't necessarily complicate things since the screen doesn't actually cache campaigns (beyond the default) - only the assets of the campaigns (such as images and videos).

So the "posts" get packaged up into effectively campaigns, which then get assigned job ids ... the only important mechanical difference here is we tracked playtime of campaigns, not of individual assets because campaigns were the purchased unit.

Now the individual assets or "posts" are the purchased unit while the "campaigns" are merely an abstraction of convenience. This means the engine would need change to report on the granularity of the asset level, which is fine.

It adds little overhead as far as I'm concerned and the campaign systems (b2b) could ignore the asset accounting and work fine.