URL Redirection for Inevitable Relocations & Subtitutions

[marcuswhybrow]

• Many assets are output to ./build/untitled-interview-yyyy-mm-dd/index.hmtl which inevitably will be updated with a proper title.
• Some assets have simple names that conflict with mentions, i.e. Asset URLs compete with mention URLs and lose #54
• Resolution means renaming assets.

Solution?

• prev-filenames frontmatter to allow programmatic creation of redirects.
• Same may be used to link to assets that used to conlict with mentions from the mention page.

[marcuswhybrow]

Using prev-filenames for a short time, I now think it's a bad approach.

• It will be used to generate old URL's from the old filename
• But that assumes that the filename to URL translation is constant across time.
• If the way a URL is derived from the file names changes, so does the "old URL" with it.
• This defeats the main purpose of prev-filenames: to figure out old URLs for redirection.

Proposals

• One could also track versions of the filename to URL tranformation. Ugly. Brittle.
• Just store prev-paths.

Prev Paths

• I went with prev-filenames because that also covers the date portion of the filename.
• A premature abstraction on my part. No expected use for that.

[marcuswhybrow]

A smaller question. prev-paths or redirect-from?

i.e. Do we add a dumb history without the behaviour being clear (prev-paths), or add the requested behaviour with the historical reason being unclear (redirect-from)?

Should this data be in the asset file at all? I like to think yes by default (simply portable). But what use is URL redirection state to someone reading the asset plain text decontextualised from the website itself?

If portability is the higher value, then prev-paths over redirect-from because that has more meaning to future consumers of this asset. It implies they can do with the data what they will, whilst indicating that it's an exhaustive record of previous website paths this asset has existed at. redirect-from implies it may have omitted entries (or added some) that weren't relevant to the specific needs of redirection at whatever point the file was last edited.

Decision: I'll go with ray-peat-rodeo.prev-paths.

N.B. Nesting within a ray-peat-rodeo field suggests this data is only useful in that context.

P.S. I considered meta as an alternative to ray-peat-rodeo as a name that requires less domain specific knowledge, but still communicates the nature of prev-paths as being not directly relevant to the asset. However, markdown fromatter is sometimes called file metadata. I wouldn't want to confusing things by having a meta section within the "metadata".