Meinung von Fachmann betr. Neutrino.conf

[Tommy]

Ich brauche mal fachmännischen Rat:

die allgemein vorherschende Methode werte aus der neutrino.conf abzufragen ist ja per "grep" die Zeile zu suchen und den Wert zu ermitteln. Wäre es nicht effektiver die neutrino.conf in ein Skript zu "includen" mit .neutrino.conf? Dazu mößte Sie allerdings wohl mit #!/bin/sh beginnen und ausführbar sein. Die Frage ist nun was ist effektiver?

Möglichkeit 1 wäre die neutrino.conf immer ausfürbar zu machen (unerwünschte Nebenefekte?)
Möglichkeit 2 wäre in der start_neutrino die neutrino.conf zu duplizieren und ausführbar zu machen.

Ich finde die Vorstellung genial in allen Skripten sämtliche System-Variablen zur Verfügung zu haben. Allerdings weis ich nicht ob es nicht nach hinten losgeht wenn man so viele Variablen deklariert, sodaß dann grep doch besser ist

[rasc]

Aeh?

die Datei wird von Neutrino gelesen, es ist halt eine Konfig-Datei.
Was willst du hier mit Shell-Scripts? Per C++ Shell-Scripts parsen?

[Tommy]

Nein - stell Dir vor, Du schreibst ein Script und benötigst z.B. den mountpoint für den Bildbetrachter. Normal gehst Du mit grep nie neutrino.conf durch und pickst den Pfad raus. Wenn die neutrino.conf ausführbar wäre würden sämtliche enthaltenen Variablen direkt verwendbar da Sie ja beim ausführen den wert hinterm "=" erhalten. Kann auch sein das das komplett dämlich ist aber - wer nicht fragt bleibt dumm

[racker]

Prinzipiell würde das schon funktionieren:

Code: Alles auswählen

. /var/tuxbox/config/neutrino.conf

nur müsstest du alle Vars mit einem Punkt vorher abändern.
z.B.: fontsize.menu in fontsize_menu

[Tommy]

Prinzipiell würde das schon funktionieren:

Code: Alles auswählen

. /var/tuxbox/config/neutrino.conf

nur müsstest du alle Vars mit einem Punkt vorher abändern.
z.B.: fontsize.menu in fontsize_menu

jo hab ich auch schon befürchtet - aber eher das ich alle Pfade in " " setzen muß.

[rasc]

Mhh, das geht aber auch einfacher - denke ich mal.

Ohne das jetzt explizit ausprobiert zu haben bzw. zu pruefen, ob die Busybox das kann:

cat ..../neutrino.conf | sh

Prinzipiell wird es aber Schwierigkeiten bei bestimmten Variablen geben und das Problem der Environment (keine Sub-Shell) muss man auch noch lösen.

[Nico 77]

Würde ein Script als Config Neutrino nicht ne ganz Ecke langsamer machen? Ich nutze außer die notwendigen garkeine Scripte mehr weil ich die Festelltung gemacht habe das es ein riesen Zeitunterschied ist ob ich etwas über ein Script progge oder in c++ beim ausführen von einem Programmteil ist. Somit denke ich in meiner Unerfahrenheit das dies keinen Vorteil bilden würde sonder zu lasten der Geschwindigkeit von Neutrino geht.

[Barf]

[Ja, ich weiss, der Thread ist alt... ]

Der eigentliche Grund warum den Vorschlag nicht gut ist, ist nicht Effizienz, sondern dass neutrino.conf Neutrino gehört, und des keine "Public interfaces" gibt. neutrino.conf ist nicht ein "Registry"-Datenbank für alle mögliche Daten.

Innerhalb von Neutrino kann mann die Klasse configFile benutzen.

Aus genau diesem Grund habe ich auch (in einem andern Thread) die XML-isierung abgelehnt.

[usul1]

Der eigentliche Grund warum den Vorschlag nicht gut ist, ist nicht Effizienz, sondern dass neutrino.conf Neutrino gehört, und des keine "Public interfaces" gibt. neutrino.conf ist nicht ein "Registry"-Datenbank für alle mögliche Daten.

Dann sollte Neutrino aber die Finger von allgemeinen Daten lassen ;-)

Wenn ich ein Mount Script habe habe ich Moment nur die Moglichkeit die Konfiguration an zwei Stellen zu speichern (und zu Pflegen) oder mein Script die neutrino.conf parsen zu lassen.
Warum nicht die Mountsachen in die fstab und Neutrino parst die wenn man die Verwaltung per Neutrino GUI machen will?

BTW: Dafür auf XML zu verzichten. Mit dem selben Argument warum das bei der services.xml fehl am Platz ist (die Kanalliste gehört ja zapit) ;-)

cu
usul

[Barf]

Wenn ich ein Mount Script habe habe ich Moment nur die Moglichkeit die Konfiguration an zwei Stellen zu speichern (und zu Pflegen) oder mein Script die neutrino.conf parsen zu lassen.
Warum nicht die Mountsachen in die fstab und Neutrino parst die wenn man die Verwaltung per Neutrino GUI machen will?

Ich vertrete der Meinung, dass Neutrino überhaubt nicht mounten soll, sondern dies soll durch automounter (/etc/auto.net) oder, möglicherweise, in /etc/fstab, gemacht werden. Falls Neutrino unbedingt mounten "muss", dann sind seine mountparameter eigentlich Neutrino-Privat. Falls Neutrino fstab-Einträge mounten will, ist keine Parsen (seitens Neutrino) notwendig.

BTW: Dafür auf XML zu verzichten. Mit dem selben Argument warum das bei der services.xml fehl am Platz ist (die Kanalliste gehört ja zapit) ;-)

Nö. Ich behaupte, dass die Datei services.xml (und bouquets.xml) zu den öffentichen Schnittstellen (public interfaces) gehören. Ist es denkbar/sinnvoll/vernünfig, diese Datein durch andere Programme zu behandeln, um Daten zu extrahieren, umwandeln, darstellen? Ist es sinnvoll/denkbar/vernünftig, diese Daten in einem Browser darzustellen? Werden diese Daten ausgetauscht, nicht nur innerhalb einem Computer? In sämtliche Fälle, ja. Eine handgepflegte Variante heisst myservices.xml. (Danke für den Anlass dies zu entwickeln )

[usul1]

Falls Neutrino unbedingt mounten "muss", dann sind seine mountparameter eigentlich Neutrino-Privat. Falls Neutrino fstab-Einträge mounten will, ist keine Parsen (seitens Neutrino) notwendig.

Ich meinte eigentlich parsen um die Möglichkeit zu bieten die Parameter (aus fstab) komfortabel in der GUI zu editieren.

Und zum mounten durch Neutrino selber: Neutrino sollte für diverse Events lieber Schnittstellen bieten wo jeder selber durch seine Scripte seine Sachen implementieren kann als selber halbherzig irgendwas zu versuchen (wobei dank recording.start und timer.record usw. schon einiges funktioniert).
Ich kann z.B. mit den Neutrino mountversuchen nichts anfangen da mein Server nur bei Bedarf eingeschaltet wird.

BTW: Gäbe der automounter eigentlich die Möglichkeit bei Bedarf ein WOL abzusetzen oder ein Scrip aufzurufen?

Nö. Ich behaupte, dass die Datei services.xml (und bouquets.xml) zu den öffentichen Schnittstellen (public interfaces) gehören. Ist es denkbar/sinnvoll/vernünfig, diese Datein durch andere Programme zu behandeln, um Daten zu extrahieren, umwandeln, darstellen?

Warum nicht in einem binären Format speichern (die Senderliste wird eh immer komplett eingelesen und komplett neu gespeichert das gibt es also auch keine Probleme mit den unterschiedlichen Feldlängen) das spart Platz im Flash und geht bestimmt schneller als ein XML zu Parsen.
Desweiteren verstehe ich auch nicht warum viele Daten doppelt gespeichert werden müssen. Die Bougetzugehörigkeit könnte ja als Flag zu den Sendern in die services.xml

Als Schnittstelle kann man ja weiterhin XML verwenden (dafür ist es ja super) indem das Webinterface z.B. beim Senderlistendownload es on the Fly nach XML konvertiert oder beim upload das XML in das interne Format konvertiert (oder das zapit machen lässt).
Das myservices kann ja meinetwegen XML bleiben.

Ich verstehe generell nicht warum auf einmal überall immer XML für interne Sachen genommen werden muß?


Aber das nur am Rande. Es bleibt ja den Programmierern überlassen wie sie das umsetzen wollen.

cu
usul