If the project were to be under taken as a series of upgrades to the existing systems, it could have proceeded as follows: '''DisplayAds Upgrades''' * original manifest notes and kept in the packing slip . * logging to be formatted with timestamp, ad number where applicable. * http uploading of images and manifests enabled. * manual entry of manifest data for indivdual ads enabled. * address information support added to packing slips / manifests. * feed set up to accept address, phone etc * ads AND advertisers fall into hierarchies * system pulls configration from central config server. '''Classifieds Upgrades''' * ads get decorations added for display and search ( milage, make , model, bedrooms, etc ) . * ads have a 'feed source' assocated with each ad so individual feeds can be reloaded safely. * ads get discrete schedule entries for each day, and for each syndication target. * ads get components ( images, pages, etc ). * newly encountered classifications are created automatically, but unapproved. * daily email sent to site admin explaining errors, actions that need to be taken, etc. * and actual admin that unites all ads. * admin to include feed configuration and syndication config. '''AdRover''' * split to a separate process for each site * to support html mail * to alert advertisers and/or account reps about pending renewal/upsell opportunities. '''AdTaker''' * expanded to Advertiser Dashboard * dashboard to include print information ( how ) * ad placement to standardized, but include an upsell plugin api similar to the manifest parser plugin api. * how to handle retail advertisers? Can this be standardized? '''PZN''' * to be an extention of AdRover * to provide personalized blocks via a topads like mechanism. This could be the first use of DistributedPZN at Scripps. ''Notes'' * users and advertisers converge under this model. There are no transient advertisers. But there are now different grades of users - UnknownUsers, KnownUsersWithNoPzn, KnownUsersWithPzn,KnownAdvertisers, KnownRetailAdvertisers