As we port functionality from the existing TO UI to the TO API, I am always looking for ways to simplify things. I can't lie. I like simple. Plus, simple == less user error. I would like to discuss the possibility of making changes to how xml_id works (at least thru the API). Here's what I propose. Feel free to poke holes in it.
1. make delivery service xml_id immutable. If you create a delivery service with xml_id = foo-bar, that is it. no changing it....ever... 2. the ds.regex in position 0 must always be of type HOST_REGEXP and in this format - .*\.xml_id\..* - this can be created for you when a delivery service is created and again, no changing this...ever...plus you don't have to fumble around with regex... I'm not 100% sure of all the problems associated with changing xml_id on a ds but I think there are a few. It can be done but I think you need to know what you're doing. And with self service coming down the pike? pipe? I would be afraid to let users change xml_id... Regarding the ds.regex in position 0, this I know: A - it has to be in the format .*\.xml_id\..* (otherwise traffic router barfs?) B - it drives the dnssec keys for the ds (if the ds is in a dnssec enabled cdn) so changing it requires a deletion of existing dnssec keys and creation of new ones C - if you change it, you better generate new ssl certs if your ds is https A and B can be done programattically but C cannot be. So back to my point. Why not simplify the whole process and make ds.xml_id and ds.regex at position 0 immutable and reduce the chance of users shooting themself in the foot? One drawback I can think of: If xml_id=foo-bar, they are locked into edge.foo-bar.cdn.domain.com which seems like an acceptable tradeoff to me as they can always add cnames if they don't like that URL. Thoughts?
