Ideas for Arc XP

We, like many customers, have migrated from a legacy platform Arc.  We would like a straightforward inteface that would allow us to perform the following functions (which we had on our existing platform:):

• For one-to-one Vanity URLs and Redirects
  • The interface should be straightforward enough so that a non-tehnical authorized newsroom user can use it safely. 
  • Ability to create, update and delete  vanityURL/rediects  (actually or legacy platform did not provide update, you had to delete and then create: Aka
  • Be able to search the existing Vanity/URL redirects for a substring of the either the Vanity URL or the destination and get a filtered display of Vanity/URLs re matches.
  • Be able to specify both on site desitinations as relative URLs and offsite destinations as full direct URLS
  • Be able to manage them on a per-site basis if you have multiple sites on Arc.
  • Be able to get a full export of existing Vanity URLS
  • Users shoud be able to enter Vanity URLs in the same manner that they would type it in use
    
    • for example they if they want a Vanity URL that would be used as <domain name>/tower, they should be able to enter /tower rather than /tower/,  If the trailing slash is needieid it can be added by the application rather than requiring the user to remember to add it.
    • It might also be useful to allow a user to specify whether they want a Vanity URL to be case-sensitive or to ignore case.   (Not a feature of our current platform);  If the Vanity URL is to ignore case for matching,my understanding is that it needs to be implemented at the origin as a many-to-one rewrite;  COnsider if this could e madie transparent to the user, and that behind the scenes the rule would be implemented where it needs to be done.
  • the Redirects should be available as soon as they are created, as they are often needed on short notice for short URLs to to provide links to online features in the next print edition.  but can't be created until the story's Canonical URL is known
    .
• For many-to-many or many-to-one rewrite rules 
  • Ability to create, update and delete them
  • Be able to search for rewrite rules that contain a specified pattern
  • Be able to use Regex syntax for both the matrching and substition patterns in rewrite rules  (will rewuire more techinical knowlege to use.)
  • Can handle both onsite and offsite destinations., DEV
  • Be able to manage the order of rewrite rules, as the order of application of rewrite rule matching patterns to the input URL will effect which rule gets appliedd ot a given input url
  • Be able to test Rewrite rules before pushing them to targted environment, and show which rule in the ruleset t would be executed and what the result would be by application of that rule.
  • Be able to specify one or more environments (Production, Sandbox, Development)  that a Rewrite rule should be active in, and when specifying a test URL, be able to select the environments it is to be tested for, so the appropriate rules will be include in the the ruleset for the test.
  • Ability to get export of rules, in the order that clearly documents their precedence  application

It is my understanding that there are 3 places where VanityURL/Redirect and Rewrite rules are implemented: Akamai, Origin and Canonical URL service (only one-to-one redirects can be implementd in Canonical URL Service. Customer Administators need better documentation of what type of rules get implemented at each of these points and why< and how they get processed in the overall flow of a request coming in to the reusulting page being delivered to customer. i

I realize the direct Access to Akamai Rules/configuration may not be possible, as you are managing it for delivery of content for many customeres and many sites.  It would be desirable for a customer  to be able t hae visibility of what the current configuration of Rewrite Rules (and caching settings as well) for their sites operating on Arc platform.\

There's more detail above then you are probably looking for in an idea. It's based on tools that we have used in the past. It is also limited in vision by that same experience and the 3-tier underlying deployment architecture that exists today.. This may require rurther customer input when some core  concepts and tools are defined for this process.  There may be specific requirements that certain customers have reguarding the volume of redirect/ rewrite rules that have been deployed at one or more of these 3 deployment tiers that might require some additional features; for example, we likely have more many-to-one redirects than is typical.

Ian Krantz

Philadelphia Media Network