Clean up device-detection terminology incorrectly ported to IP Intelligence

[justadreamer]

Summary

Several comments, documentation strings, and code references were ported verbatim from device-detection-go and still reference device-detection-specific concepts (Hash algorithm, User-Agent, device detection) that have no relevance to IP Intelligence. Additionally, the mixed examples (which legitimately use both DD and IPI) introduce a device-detection-go dependency at the root module level.

Findings

1. Core library - "device detection" in comments

The core IP Intelligence engine describes itself as device detection:

• ipi_onpremise/onpremise.go:16 - "Engine is an implementation of the on-premise (based on a local data file) device detection."
• ipi_onpremise/onpremise.go:61 - "New creates an instance of the on-premise device detection engine."

Both should say "IP intelligence" instead of "device detection".

2. Mixed examples - User-Agent and device detection terminology

The examples/mixed/ directory contains examples that combine DD and IPI. While these intentionally use device-detection APIs, there are naming/documentation issues:

examples/mixed/getting_started_console/main.go:

• Line 26: "The example processes four hardcoded evidence records (User-Agent header + client IP)" - conflates DD and IPI evidence
• Lines 51, 63, 70, 78, 85: Variables named userAgent with actual UA strings
• Line 108: Evidence key "User-Agent" being added
• Line 123: Function parameter results *dd.ResultsHash
• Line 212: Default path "51Degrees-LiteV4.1.hash"

examples/mixed/getting_started_web/main.go:

• Line 37: ".hash data file" in comment
• Line 97, 187: *dd.ResultsHash type references
• Line 115: "Device Detection error" log message
• Line 233: dd.NewConfigHash(dd.LowMemory), ddOnpremise.WithConfigHash(ddConfig)

examples/mixed/getting_started_web_ui/main.go:

• Line 28: "Device detection results (hardware, platform, browser) in a left column"
• Line 133, 221, 316: *dd.ResultsHash type references
• Line 151, 502: "Device Detection error" and "Failed to create Device Detection engine" log messages
• Line 365: HTML content "Device detection using User-Agent and request headers"

Test files:

• examples/mixed/getting_started_web/web_test.go:109 - Header.Set("User-Agent", ...)
• examples/mixed/getting_started_web_ui/web_test.go:105,143 - Header.Set("User-Agent", ...)

3. "Hash" references

• examples/common/hash.go - file named "hash.go" with a GenerateHash() function (may be a misnomer from DD porting, even if it uses FNV hashing internally)
• Multiple .hash data file references in mixed examples and CI scripts

4. TAC references in CI

• ci/run-integration-tests.ps1:14 - $env:DD_DATA_FILE = "$PWD/assets/TAC-HashV41.hash" (TAC-Hash is a DD data format)
• ci/fetch-assets.ps1:9 - "TAC-HashV41.hash" in asset list

5. Root-level go.mod includes device-detection-go dependency

• go.mod:9 - require github.com/51Degrees/device-detection-go/v4 v4.5.9

This dependency is only needed for the mixed examples, not the core IP Intelligence library. It should ideally be isolated (e.g., separate go.mod in examples/mixed/) so the core module doesn't pull in device-detection-go.

6. GitHub workflows pass Device Detection secrets

• .github/workflows/nightly-pipeline.yml, nightly-publish.yml, nightly-pull-requests.yml - pass DeviceDetection and DeviceDetectionUrl secrets. These are only needed for mixed examples but are part of the main workflow.

Suggested approach

1. Fix core library comments in ipi_onpremise/onpremise.go - replace "device detection" with "IP intelligence"
2. Separate mixed examples into their own Go module with a separate go.mod so the root module doesn't depend on device-detection-go
3. Review examples/common/hash.go - rename if it's a DD leftover, or add a comment clarifying it's a general-purpose hash utility
4. Update CI scripts to clearly separate IPI and DD data file handling
5. Consider isolating DD-related workflow secrets to only the jobs that need them
6. Add clear documentation in mixed examples that they intentionally combine both products

[justadreamer]

breaking changes are possible, but there are no known clients using Go, need to verify with @Tracy51D