[RFC] Definable standard directory for "tmpfs" Plugins?

fnu: Ja, dann ist das was anderes

Dann könnte man das ganze Cachedir in ein tmpfs packen. Auch ein interessanter Ansatz...

Es ist schon traurig, daß man sich nichtmal bei sowas primitivem wie einem temporären Verzeichnis auf einen einheitlichen Standard einigen kann.
"FHS - my a**" kann ich da nur sagen ;-).

Zum Thema: VDR selber wird kein "tmpfs" brauchen. Wenn er temporäre Daten hat, die nicht auf einer physikalischen Platte gehalten werden können, dann hat er die einfach im RAM. Und ebenso würde ich es auch bei Plugins sehen. Entweder die Daten werden schnell benötigt, dann sollten sie direkt im RAM gehalten werden. Oder es macht nichts, wenn der Zugriff etwas länger dauert, dann können sie hingeschrieben werden, wo immer "/tmp" hinzeigt. Den Bedarf für ein spezielles "tmpfs" sehe ich nicht. Und wenn sich ein Plugin darauf verlässt, daß es dort auch wirklich ein "tmpfs" vorfindet, dann kann es auch böse auf die Nase fallen, wenn es dann doch nur "/tmp" auf einer physikalischen Platte ist.

Wenn's aber gar nicht anders geht, dann können sich die Plugins ja auch auf eine Environment-Variable einigen, z.B. TMPFS ;-).

Klaus

Zitat von kls

Wenn's aber gar nicht anders geht, dann können sich die Plugins ja auch auf eine Environment-Variable einigen, z.B. TMPFS ;-).

Genau darum gehts ja hier Der VDR gibt das vor und alle wissen was zu tun ist. Ohne Vorgabe vom VDR macht eh jeder was anderes

Es geht ja nicht darum irgendwelche Funktionen in den VDR zu packen, es geht nur darum das er VDR eine Variable (die beim VDR an der Kommandozeile angegeben wird, wenn nicht dann ist der Default VDR üblich das Video Directory) von den Plugins abgefragt werden kann *).

Alternativ würde es auch reichen in der PLUGINS.html zu schreiben das für kleine Temp Dateien der Pfad zu nutzen ist der in der Umgebungvariablen VDR_TEMP vorgegeben ist.
Oder man erstellt im wiki ne Plugin Writing Guide, die das was in PLUGINS.html steht ergänzt. Aber es wäre ja schöner wenn direkt im VDR Core festgehalten würde.

cu

*) Die Zusatzfunktion das der VDR bei der Abfrage des Pfades das Verzeichnis ggf. erstellt (so wies halt auch ConfigDirectory() tut) wäre dann noch Luxus.

Zitat von Keine_Ahnung

Genau darum gehts ja hier Der VDR gibt das vor und alle wissen was zu tun ist. Ohne Vorgabe vom VDR macht eh jeder was anderes

Es geht ja nicht darum irgendwelche Funktionen in den VDR zu packen, es geht nur darum das er VDR eine Variable (die beim VDR an der Kommandozeile angegeben wird, wenn nicht dann ist der Default VDR üblich das Video Directory) von den Plugins abgefragt werden kann *).

Wieso sollte der Name einer Environment-Variablen beim VDR-Start angegeben werden?
VDR hat mit dieser Variablen nichts am Hut! Und wenn die Plugins ihren Job *richtig* machen würden (siehe mein vorheriges Posting) dann bräuchte es diese ganze Diskussion auch nicht!

Zitat

Alternativ würde es auch reichen in der PLUGINS.html zu schreiben das für kleine Temp Dateien der Pfad zu nutzen ist der in der Umgebungvariablen VDR_TEMP vorgegeben ist.
Oder man erstellt im wiki ne Plugin Writing Guide, die das was in PLUGINS.html steht ergänzt. Aber es wäre ja schöner wenn direkt im VDR Core festgehalten würde.

cu

*) Die Zusatzfunktion das der VDR bei der Abfrage des Pfades das Verzeichnis ggf. erstellt (so wies halt auch ConfigDirectory() tut) wäre dann noch Luxus.

Ich möchte sowas nicht im VDR-Core haben, weil ich es für unnötig halte!
Entweder eine Datei ist einfach temporär und kann auf die (evtl.) physikalische Platte geschrieben werden, dann haben wir mit "/tmp" bzw. getenv("TMP") oder mktemp() etc. bereits seit vielen Jahren einen standardisierten Ort hierfür. Oder die Daten sind so kritisch, daß sie immer schnell verfügbar sein müssen, dann sollten sie auch explizit im RAM gehalten werden.

Klaus

Naja, der Punkt ist halt das es in der Praxis dann halt doch nicht so einfach ist wie du sagst.

Die Distribution für nen 128MB RAM Router möchte evtl. nicht das 500MB Daten im RAM gehalten werden, die Distribution für High-End super cool 4 GB RAM Hardware möchte aber auch nicht das ne 2 MB Datenbank in /tmp liegt und dort für ne dauerhafte HDD (oder schlimmer SSD) Aktivität sorgt.

Es wäre halt Service für Distributionen/Nutzer gewisse Dinge zentral konfigurierbar zu machen, anstatt zu verlangen das bei 20 Plugins sepperat zu konfigurieren.

Zitat von kls

Wieso sollte der Name einer Environment-Variablen beim VDR-Start angegeben werden?
VDR hat mit dieser Variablen nichts am Hut!

Nein, so war das nicht gemeint. Die Idee war als VDR Startparameter z.B. --tmpdir einzuführen (also z.B. --tmpdir /dev/shm/vdr) und Plugins erhalten per TempDirectory("pluginname") als Rückgabe "/dev/shm/vdr/pluginname"

Zitat von kls

Und wenn die Plugins ihren Job *richtig* machen würden (siehe mein vorheriges Posting) dann bräuchte es diese ganze Diskussion auch nicht!

Um etwas "richtig" zu machen brauchts aber erstmal ne klare Definition was "rchtig" ist. Sonst machst jeder auf seine eigene Weise "richtig". Und um diese klare Definition gehts hier ja.

cu

Mit richtig ist wohl gemeint , das

für den Fall xmltv2vdr:
- :memory: DB verwendet wird und beim herunterfahren dann ATTACH und es so in eine physikalische DB überführt wird. Beim Start dann andersrum. So würde man keine RAM Disk benötigen

Für den Fall osdteletext:
- Die Datenstruktur im Speicher gehalten wird.

Aber aus besagten Gründen ist richtig nicht so einfach zu entscheiden, gerade im Falle von xmltv2vdr

Zitat von steffen_b

Mit richtig ist wohl gemeint , das

für den Fall xmltv2vdr:
- :memory: DB verwendet wird und beim herunterfahren dann ATTACH und es so in eine physikalische DB überführt wird. Beim Start dann andersrum. So würde man keine RAM Disk benötigen

Für den Fall osdteletext:
- Die Datenstruktur im Speicher gehalten wird.

Aber aus besagten Gründen ist richtig nicht so einfach zu entscheiden, gerade im Falle von xmltv2vdr

Alles anzeigen

Wobei xmltv2vdr mit "im Speicher halten" die Leute, die den VDR auf nem Router laufen lassen, wohl auch nicht glücklich macht wenn sie alle 60 Sender für 21 Tage hohlen

TempDirectory() passt schon. Da setzt es jeder dorthin wo es ihn glücklich macht. Und wenn Plugins Daten (die sich jederzeit wiederbeschaffen lassen) über den Reboot behalten wollen, dann kopieren sie die am Ende nach CacheDirectory() (und wenn sie wichtig sind nach ConfigDirectory()).
Sowas wie Burn mit seinem --datadir wäre da natürlich aussen vor (weil das sind ja gerne 10GB), --tempdir in Burn könnte dann aber automatisch von TempDirectory() bestimmt werden.

BTW: epg.data wäre da auch son Kandidat. Oder das speichern im Betrieb generell deaktivierbar machen. Aber das möchten wir jetzt nicht diskutieren

Wobei, wenn Klaus nicht mag dann wäre ne Plugin Writer Guideline im wiki evtl. ne brauchbare Ersatzidee!?

cu

Als alternativen Denkansatz würde mir noch einfallen, innerhalb des Cachedir eine Verzeichnisstruktur aufzubauen, z.B. $CACHEDIR/tmp und $CACHEDIR/run, welche dann ggfs. als Symlink auf geeignete Verzeichnisse verlinkt werden. Hilfsfunktionen, die $CACHEDIR/tmp/$PLUGINNAME generieren, könnte man ggfs. auch noch bereit stellen, auch sollte klar sein, das Verzeichnisse bei Bedarf noch erstellt werden müssen.

Andererseits wäre es auch eine dankbare Lösung, dem osdteletext-Plugin endlich mal eine In-Memory Datenstruktur zu verpassen. Im STL-Zeitalter ist es ja nun wirklich einfach, komplexere Datenstrukturen aufzubauen, einfacher jedenfalls, als eine Verzeichnisstruktur auf Platte zu managen.

Gruß,

Udo

Zitat von Urig

Andererseits wäre es auch eine dankbare Lösung, dem osdteletext-Plugin endlich mal eine In-Memory Datenstruktur zu verpassen. Im STL-Zeitalter ist es ja nun wirklich einfach, komplexere Datenstrukturen aufzubauen, einfacher jedenfalls, als eine Verzeichnisstruktur auf Platte zu managen.

Ja, das wäre ein echter Gewinn. Zumal, soweit ich das sehe, der Code von osdteletext mittlerweile so angepasst wurde, dass mehrere Cache-Lösungen eingebaut werden können. Für diejenigen, die die Cache-Dateien extern interpretieren wollen kann der alte Mechanismus also bleiben. Standard sollte aber sein, dass solche Daten im RAM angelegt werden, denn Teletext-Daten müssen einen Reboot definitiv nicht überleben und es macht auch keinen Sinn für diesen Cache mehr oder weniger permanent auf der Festplatte rumzurutschen.