reverse domain name notation

This naming convension exists because of collisions.

The naming convention piggybacks on an unrelated system that enforces unique domains. The convention works like this:

  1. You lease, or already have, a domain.
  2. DNS enforces that only one instance of your domain can exist. You alone are leasing that domain.
  3. Everyone names their files based on a domain name they alone control and nobody's filenames can collide.

Neat.

If you lease google.com, and you use reverse domain name notation to prepend the filename of a .plist with com.google, then, assuming everyone else is following the same convention, nobody else will name their files in a manner that collides with yours.

This convention can be seen in practice on many systems. In macOS, the LaunchAgents directory contains files named with reverse domain name notation, and on Android in its Data directory.

Reverse domain name notation is useful when there is a location that tends to hold files whose names are not all controlled by a single user.

When Chrome drops a .plist into ~/Library/LaunchAgents, that file is being created in a location which can hold other .plist files deposited by other programs that are not the Chrome browser for macOS.

Employing reverse domain name notation for such a file would be sensible. By naming this file com.google.GoogleUpdater.wake.plist, the file will not collide with another file. Even if that another file is also a GoogleUpdater.wake.plist, using reverse domain name notation makes that other file's full name different. Potentially ca.google.GoogleUpdater.wake.plist.

🐭