Hallo. Am Dienstag, 8. September 2009 schrieb Micha Lenk: > Es ist schön und wunderbar und wichtig, Wünsche zu äußern -- manche > Dinge sind aber eben nicht so trivial, wie sie auf den ersten Blick > erscheinen. Daher musst du schon verstehen, wenn ein (bei wirklichen > Trivialitäten vielleicht eher mal akzeptierter aber trotzdem genau so > nerviger) fordernder Unterton auf Widerstand stößt und dieses > Missverständnis erstmal aufgeklärt werden muss. > > Der Wunsch, sich mit http_proxy usw. anstelle von GWEN_PROXY möglichst > an die Konventionen zu halten, ist jedenfalls angekommen, denke ich. > Jetzt muss es halt nur noch jemand *machen* -- wie immer... :)
Schon klar soweit. ;-) Du weißt sicher: Nichts hält länger als ein Provisorium. Wenn die GWEN_PROXY-Variable jetzt ein Provisorium ist und "eigentlich" schon lange geändert werden sollte, dann würde ich auf diese Aussage nicht viel geben und weiter damit rechnen, dass uns diese Methode noch lange erhalten bleibt. Das ist definitiv kein Vorwurf und keine Eigenheit dieses Projekts, es ist nur irgendwie ganz oft so, im ganzen Leben. :) Ergo würde ich bei der aktuellen Provisoriums-Lösung einfach die Variabeln-Namen und -Reihenfolge erweitern, das sollte wirklich einigermaßen trivial zu programmieren sein. Wenn man länger beim Variablen-Konzept bleibt und dann vielleicht trotzdem mal intern was ändert (so dass gwen weiß was über die Verbindung läuft), könnte man wenigstens das User-Interface gleich lassen. > Ich bin übrigens gänzlich gegen die Nutzung von Umgebungsvariablen (was > einen Großteil dieser Diskussion obsolet machen würde) sondern dafür, > dass der Proxy über eine Gwen-API-Funktion (oder -Parameter) explizit > konfiguriert werden kann. Da wir hier von Gwen *und* von AqBanking reden, ist es erstmal egal, wer welche Variable ausliest und verarbeitet. Es ist für einen Benutzer allemal einfacher, systemweit eine Hand voll eindeutiger Variablen zu setzen als bei jedem Programm im configfile was einzutragen. Von daher würde ich die Variablen nicht völlig über Bord werfen sondern den Code langfristig vielleicht so ändern, dass die Anwendung die Variablen liest und der Library dann intern sagt was zu tun ist. Auch da wäre es gut, wenn das User-Interface durch diese Änderung nicht anders ist. > Das gibt einer Anwendung wesentlich mehr > Möglichkeiten, Proxy-Einstellungen zu berücksichtigen (z.B. > KDE-Proxy-Einstellungen usw. usf.) und benötigt keinen Umweg über eine > Umgebungsvariable. Ich glaube KDE setzt bei entsprechenden Einstellungen die passenden Variablen für die aufgerufenen Programme. ;-) > Aber so weit ich weiß, war die Umgebungsvariable > GWEN_PROXY sowieso nur ein Hack, der die Nutzung eines Proxy überhaupt > mal ermöglicht hat... Genau. Und dieser Hack hatte irgendwie einen provisorischen Übergangs-Namen, der nun doch nicht gleich wieder abgeschafft wurde. ;-) Gruß, Bernd -- Press <ESC> to detonate or any other key to explode
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________ Aqbanking-devel mailing list Aqbanking-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/aqbanking-devel
