GitLab

Sitehub Details :

The Sitehub House Ads architecture is approximately as seen here:

Technologies used: Nitrite for the database, mostly for it's document database approach. GSON/Volley for HTTP serialization/de serialization Lottie for display of ads

Specific details should either be gleaned from code (/support/HouseAds) or information should be requested. The key principal is "on demand" house ads. Data collection/maintenance should be done separately from display related tasks. House ads, when requested to play or prepare, should anticipate needing to play INSTANTLY and should prioritize displaying something and sticking to it than to deciding what "is best". IF optimization in what to play and pre-play-checking is desired, you should have a background task that coordinates and plans that. The display portion should simply choose one thing to play as quickly as possible and play it.

Unknowns: NONE of the APIs were complete or started when i left. They should be distinct from the APIs for the website. The format should be EXACTLY as is already specified: http://repo.buzztime.com/kbungo/local_ad_manager/tree/master/server#sitehub-aggregate . Reporting API can be found in the Reporting ticket. There is a comment specifying the API i expect. Downloading uses ID as a key and the HASH in compositions and assets is what drives the updating of those files since their IDS may not change often or ever. The hash is NOT used to verify the file currently, but should be eventually.

Re: block-diagram

The block diagram as present doesn't match what i would expect for the server layer.

The front end has a set of calls it makes to Mystery Machine APIs. Mystery Machine verifies permissions and then makes a call to the get_stored_procedure API in cheerios. Please let me know if this is not understood and I can make corrections if sent a file or i can rediagram it.

Missing Ticket links

TBD