@er13
schon klar dass du nicht "böses" wolltest
ich habe mal ein bisschen den code des daemons von transmission studiert - und der kann ja im prinzip kaum was. nun ist es natürlich die frage, falls man dort weiterentwickeln würde, wo denn die neuen features hin sollen - direkt nach libtransmission oder in den daemon? denn zur zeit sieht es für mich bei dem daemon einfach nur danach aus, einen prozess von libtransmission zu forken - dieser wird dann per rpc-server (client muss aktiv was senden) kontrolliert und fertig. das geht ja etwas mit dem auseinander, was in webtransmission passiert ist, nämlich ein aktives programm im hintergrund, das kontinuierlich den status mittels (hauptsächlich) libtransmission-aufrufen überwacht und änderungen durchführt, wenn nötig.
man müsste mal fragen, wie das von den transmission-entwicklern gewollt ist. aber da es ja z.b. sowas wie automatischen stop bei erreichter ratio auch nicht gibt (was an sich einfach zu implementieren ist), sollte soetwas sicherlich in den daemon - nur müsste man sich dann was überlegen, wie man mittels rpc-server von libtransmission sachen an den daemon weiterleitet und evtl. auch zurück (falls es nicht schon irgendwie geht, so weit bin ich da noch nicht durchgestiegen) - denn der rpc-server ist im prinzip ne feine sache, jetzt wo ich endlich verstanden habe, wozu der gut ist
sollte das ganze direkt in libtransmission rein, entfiele natürlich die sache mit dem rcp-server-durchschleifen - nur müsste ich mich dann ordentlich in die internals von libtransmission einarbeiten, was sicherlich nicht so einfach ist - und man könnte auch mehr kaputt machen
falls es möglich ist, im daemon rpc-aufrufe zu verarbeiten, könnte man ganz einfach die neuen funktionen in den daemon von transmission implementieren und die dann mittels des neuen webinterfaces kontrollieren. man müsste sich dann "nur" in das neue webinterface einarbeiten (abgesehen von den rpc-aufrufen) - das wäre im prinzip das, was ich am besten fände.
ansonsten bestünde noch die möglichkeit, das webinterface von webtransmission auf den rpc-server umzustellen - damit fiele der großteil des unnötigen krames mit den sockets heraus, wie du sagst, und am ende hätte man einen daemon, der wirklich nur die routinen im hintergrund abfährt und libtransmission per interner aufrufe kontrolliert und ein webinterface, das libtransmission direkt per dessen rpc-server ohne umweg über den daemon kontrolliert (und nur im allernötigsten fall auf den socket zurückgreift, um sachen an den daemon zu senden, wie z.b. nach welcher ratio ein torrent gestoppt werden soll).
dann zumindest hätte man mal eine übersicht, und könnte evtl. besser entscheiden: direkt in libtransmission oder doch lieber die möglichkeit, den daemon per rpc-server in libtransmission zu kontrollieren, einbauen und dann den rest im daemon.
also wie ihr seht: ich bin grad noch am rumüberlegen, aber im prinzip bin ich "bereit für neues"
nur leider geht das nicht von heute auf morgen...
@eMd
sehr komischer fehler. dürfte so eigentlich nicht vorkommen. ehrlich gesagt weiß ich nicht, was da schief laufen könnte. steht evtl. etwas im webtransmission.log (mit debuglevel -v3)?
moment mal - hauptfenster ganz unten? sicher, dass du die neuste version hast (Webtransmission 1.42-v2.3b-svn101 ( 27.12.2008 ))?
