Metadaten-Provider ergänzen: Emunation.ch (DVD/Blu-ray)

[vulture20]

Was fehlt

Metadaten-Provider Emunation.ch für DVD/Blu-ray (briefing 8.2) fehlt noch. Aktuell ist für DVD/Blu-ray nur UpcMdbProvider implementiert.

Fundstelle

Neue Klasse unter backend/app/Domain/Metadata/Providers/DvdBluray/, implementiert App\Domain\Metadata\Contracts\MetadataProviderInterface (siehe UpcMdbProvider als Vorbild), Eintrag in MetadataProviderRegistry::defaultProviders() (backend/app/Domain/Metadata/MetadataProviderRegistry.php). Danach automatisch über metadata_plugins (Admin-API) togglebar.

Bezug

briefing 8.2 (DVD/Blu-ray: Amazon, UPCMDB, Emunation.ch).

Warum niedrige Priorität

Das Erweiterungsmuster (Interface + Registry) ist bereits etabliert und getestet, es fehlt nur an dieser konkreten Implementierung. Unabhängig von den übrigen fehlenden Providern umsetzbar.

[vulture20]

Rechercheergebnis: Öffentlicher API-Vertrag fehlt

Bevor implementiert wird, wie in dieser Session sonst üblich der Versuch, den echten API-Vertrag zu verifizieren (wie bei UpcMdbProvider/OpenLibraryProvider/MusicBrainzProvider gegen die jeweils öffentlich dokumentierten APIs geschehen) — bei EMUnation.ch ist das nicht möglich:

• Die Website (emunation.ch, disccaptain.php, disccaptain-manual.php) beschreibt den Barcode-Lookup nur funktional ("You scan the barcode, the title and year arrive from EMUnation"), nicht technisch.
• Das Disc-Captain-Handbuch sagt explizit: "If you'd like a copy of the developer manual or the source, drop us a message" — die API-Dokumentation (Endpunkt-URL, Auth-Mechanismus, Response-Schema) ist ausschließlich auf Anfrage direkt bei EMUnation erhältlich, nicht öffentlich einsehbar.
• Es existiert ein API-Key-Konzept ("The key is what authorises live barcode lookups against the public catalogue"), aber ohne jede technische Spezifikation dazu.
• Keine auffindbare Referenzimplementierung (kein öffentliches GitHub-Repo, keine Client-Bibliothek) und keine über Websuche auffindbare Endpunkt-URL.

Warum das ein Blocker ist, kein Detail

Ein Provider, der gegen einen geratenen/vermuteten Endpunkt implementiert wird, wäre schlechter als gar keine Implementierung: Er würde in metadata_plugins als aktivierbar erscheinen, bei jeder echten Anfrage aber vermutlich no_match liefern — genau die Fehlerklasse, die in Issue #17 bereits als kritisches, schwer zu diagnostizierendes Problem dieser Codebase identifiziert wurde (ein scheinbar aktivierter Provider, der in Wahrheit nie einen Treffer liefert). Ohne Möglichkeit, das Verhalten live zu verifizieren, lässt sich das nicht ausschließen.

Voraussetzung für die Umsetzung

Dieses Issue bleibt offen, bis einer der folgenden Wege den echten API-Vertrag liefert:

• Ein Repo-Verantwortlicher fordert die Entwickler-Doku/einen API-Key direkt bei EMUnation an (über deren Kontaktformular, s. o.) und stellt Endpunkt-URL, Request/Response-Format und einen Test-Key bereit, oder
• eine andere verlässliche Quelle für den API-Vertrag wird gefunden.

Sobald der Vertrag bekannt ist, ist die eigentliche Umsetzung nach dem etablierten Muster (UpcMdbProvider als Vorbild, Registrierung in MetadataProviderRegistry::defaultProviders()) unverändert unaufwendig.