TRex hat geschrieben:Ich wollte damit nicht ausdrücken, dass ich es nicht für sinnvoll halte, sondern dass das Wissen bei den Mozilla-Mitarbeitern anders verteilt ist als bei Videolan.
Ja klar, glaube da haben wir aneinander vorbeigeredet. Ich bezog mich nicht auf das unterschiedliche verteilte Wissen, sondern auf die Anzahl der Leute die programmieren und entwickeln.
Ein Video Player muss alles( oder ziemlich vieles davon ) was an Multimedia abspielbar ist wiedergeben können und da sind AVCodecs, FFMPEG, Xine usw. nebst all den möglichen Audiocodecs ( die als Vergleich wie eine Art Api angesehen werden können, nebst den 3 Linux Audio Möglichkeiten und Distris ) und zusätzlich auch auf Sicherheit setzen ( nicht das Angreifer via einen Video durch einen Videoplayer den Sprung ins Rechner " leicht " bewältigen könnem ).
Wenn ich mir so alle Gebiete eines scheinbares, einfaches Videoplayer angucke sind es relativ sehr viele ( abgesehen davon, von ihren Podcasts usw. ). Daher geht es so in meiner Logik nicht ganz auf, die Diskussion der Bewältigung des Aufwandes, und wie pferdefreund, als Programmierer es sehr simpel erklärt hat kann ich es von Mozilla noch weniger nachvollziehen.
Ein Browser ist im Prinzip nichts andere als ein " Viewer / Reader " mit nur Read Berechtigung, das erst durch den
Tag Befehl und durch " Textfelder " diese Berechtigung in vorgesehene Felder aufhebt. Was daran soooo aufwendig sein soll erschliesst sich mich nicht, auch weil ich nun gut 3 GTK-2 UI reprogrammiert habe, für kleine Texte und Bilder auch als Viewer. das Grundcode ist immer das selbe. Bei einer UI kann es sogar dynamisch Pfade bestätigen in " readonly " Textfelder.
Nun, langer Rede kurzer Sinn wie man so schön sagt...
Weil ich ein wenig GTK-2 UI gestalten und reprogrammieren kann und besonders im HTML in Kombination mit JS und " onclick " Befehle ( was auch JS ist ) dahinter gesehen habe ist die Aufwand Frage, respektive wegen Vereinfachung für die Entwickler
für mich nicht akzeptabel. Auch weil das zu darstellende Inhalt von Website Programmierer zur Verfügung gestellt werden muss und der Browser nur einen interaktives Viewer ist. Vielleicht wird eine JS-Query entwickelt werden, die auch die Audio API's direkt mit HTML-5 einbinden kann, dann muss der Browser wiklich nur noch Formulare Eingaben weiterleiten und Texte und Bilder darstellen können.
Systemd und PulseAudio, hmmm, nein danke.