@derreisende77 sagte in Keine Rückmeldung von MV beim Anlegen neuer Abos:
Guter Ansatz, aber leider falsch gedacht. Folgendes Beispiel: Der crawler sucht bei Sender X einmalig die Informationen und packt sie in die Filmliste. Dann hast Du einmal Traffic um die Infos zu bekommen, jeder Client lädt von uns die Daten per Filmliste.
Gegenbeispiel: Der Crawler durchsucht 10000 Seiten, findet 3000 Sendungen, aber nur 300 davon werden überhaupt nachgefragt … auch so generiert man Overhead.
Deshalb hatte ich angedeutet, dass man, um so etwas zu optimieren, eigentlich vieles über die Nachfrage nach den Sendungen wissen müsste.
In letzter Konsequenz koennte ich mir sogar ein Design vorstellen, das die von Clients er-crawl-ten Ergebnisse in einer zentralen Datenbank sammelt, von wo sie dem naechsten Client gleich uebergeben werden koennten - eine Art Cache, wenn man so will.
Das ist ein guter Ansatz über den wir auch schon häufig diskutiert haben und es auch schon Prototypen hierzu gab. Folgende Probleme ergeben sich hierbei:
Wie wird die Offline-Fähigkeit aufrecht erhalten? Die MediathekView-App soll offline nutzbar sein. Das war der Grund der Entwicklung.
Offline? Zumindest der Download der Video-Dateien muss ja wohl online erfolgen?
Wird der Nutzer gezwungen, die Mitarbeit durch Nutzung der Software zuzulassen? Oder kann er sich aus verschiedenen Aufgaben ausklinken? Welche Auswirkungen hat das dann ggf. für ihn?
Ich hatte eigentlich nicht an Zwang gedacht - die Rückführung der ermittelten Daten war eigentlich sowieso nur eine Zusatzidee. Die Daten könnten total anonym eingereicht werden und würden ja sowieso nur die Inhalte der Mediatheken reflektieren, die man nur deshalb nicht von dort holt, um die Bandwidth von deren Servern zu schonen.
Wie stelle ich sicher dass der Nutzer bevor er zustimmt DSGVO konform über die dadurch erhobenen Daten aufgeklärt wird? Er muss ja in Teilen nachverfolgbar werden für den Server wenn Aufträge versendet und Antworten zurück kommen. Zum Beispiel macht es ja keinen Sinn Aufträge für österreichische oder schweizer Einträge an deutsche Clients zu senden da die in der Regel am Geofence scheitern und nur “verboten” dann zurück liefern.
Ein paar exzellente Gründe, kein Modell mit “Auftragsvergabe” zu entwickeln.
Auch nicht zu vergessen: Wie vehindere ich zuverlässig das irgendwelche Clowns den Quellcode laden, ihn etwas modifizieren und Blödsinn an den Server zurück liefern? Der Quelltext ist nicht closed-source und die gelieferten Informationen können nicht 100% auf Zuverlässigkeit geprüft werden.
Das ist allerdings ein interessantes Problem … (wobei “closed source” ja bekanntlich der schwächste Schutz ist, den man sich vorstellen kann.) Im Extremfall würde das das Cachen der vom Anwender ermittelten Daten hinfällig machen - mehr nicht. Wäre schade.
Alles in allem, das war jetzt so noch nicht als fertiges Konzept gedacht, aber so ganz abwegig scheint es ja nicht zu sein, wenn darüber schon vorher nachgedacht wurde … Meine Idee war lediglich, Möglichkeiten zu suchen, wie man mit möglichst geringer Belastung der Sender-Server einen möglichst guten Überblick über deren Angebote gewinnen kann - und da seid ihr schon ziemlich weit gekommen, aber hier und da klingt es doch durch, dass die Belastung manchmal doch ein Stück höher ist als man sich wünschen würde.
(Über Modelle, bei denen die Clients - z.B. aus Sicherheitsgründen - per API Code auf den MV-Servern aufrufen, will ich jetzt mal noch gar nicht nachdenken, denn da sehen wir uns vermutlich auch deutlichen Grenzen des Möglichen gegenüber.)
