Joachim Merkel <[EMAIL PROTECTED]> wrote on 27.03.04:
> Michael Heydekamp ([EMAIL PROTECTED]) schrieb:
>>> Jetzt kann ich keine zwei gmx-Boxen einrichten,
>> Warum nicht?
>>> sondern mu� eine anders nennen,
>> Wie der Boxname hei�t, ist doch (bei RFC/Client) v�llig egal.
> Jedenfalls gings unter ZConnect nicht und ich habe es daher
> beibehalten, vd. Namen zu verwenden, die dann einen Teil der Adresse
> bilden.
Ja klar, das ist die ZConnect-Denke. Bei RFC/Client nennst Du die Boxen
meinetwegen "Box1" und "Box2", das hat null Einflu� auf die Adresse, die
Du dort verwendest (sollte auch in der Hilfe zum Boxnamen stehen).
> Wenn ich also zwei Accounts habe: [EMAIL PROTECTED] und [EMAIL PROTECTED], dann
> kann ich kaum zwei Boxen mit gmx einrichten.
Bei RFC/Client schon. Bei ZConnect m��te das BTW auch gehen, wenn man
den Schalter "Absender [EMAIL PROTECTED]" aktiviert.
>> Falls es Dir darum gehen sollte, die Nachrichten mehrerer Boxen mit
>> einem Anruf versenden zu k�nnen: Probiere doch mal, unter
>> "Zus�tzliche Server" die Boxen, deren Nachrichten mitversendet
>> werden sollen, einzutragen. Das war ein Szenario, das ich ohnehin
>> nochmal testen wollte.
> Das ist mir jetzt noch v�llig fremd, aber liest sich erstmal gut. Ich
> will nur zwei vd. Accounts mit vd. Usernamen bei demselben Anbieter
> verwalten, die unter vd. Boxnamen unter XP erscheinen m�ssen.
Prinzipiell geht das - von dem oben angesprochenen "Multiserver-Netcall"
mal abgesehen - nat�rlich mindestens mal mit zwei Boxen und Netcall/
Spezial. Wobei man da wieder was f�r UKA_PPP basteln m��te, um die
Verbindung nach dem Poll der ersten Box nicht zu trennen.
>> Hmm, wird aber wohl daran scheitern, da� die Batch derzeit nur das
>> Spool der pollenden Box beachtet. Sie m��te im Grunde diesen Eintrag
>> in der BFG auswerten und die Nachrichten aller dort eingetragenen
>> Boxen ins UKA_PPP-Spool kopieren.
> Aha.
UKA_PPP unterst�tzt von sich aus nat�rlich keinen Multiserver-Netcall
eines Boxtyps, den es zu dieser Zeit noch gar nicht gab. Will man sowas
haben, mu� man es von au�en dranflicken oder UKA_PPP umschreiben.
Und "von au�en dranflicken" hie�e:
FreeXP legt per Design die zu versendenden Nachrichten der Pollbox wie
die der in der Pollbox eingetragenen "zus�tzlichen Server" in den box-
spezifischen Spool-Verzeichnissen ab.
Ein Client, der dieses Konzept unterst�tzt (und das macht UKAW mit dem
Parameter /light, UKAD hingegen nicht), w�rde jetzt die Nachrichten aus
allen diesen Verzeichnissen �ber die bei den jeweiligen Boxen
eingetragenen Mail- und News-Server versenden.
Da UKA_PPP das nicht macht, m��te die Batch daf�r sorgen, da� nicht nur
die Nachrichten der Pollbox, sondern auch die der "zus�tzlichen Server"
ins UKA_PPP-Spool kopiert werden.
Da mu� man sich dann allerdings nochmal genau ansehen, wie man das
Unversandt-Handling sauber hinbek�me. Das wird nicht ganz trivial.
>> K�nnte man sich mal ansehen, wenn ich das Envelope-Handling einbaue,
>> da mu� ich ohnehin auf BFG-Eintr�ge zugreifen.
>> Aber zum einen ging der Versand der Nachrichten mehrerer Boxen
>> gleichzeitig unter ZConnect bisher auch nicht, und zum anderen hat
>> das immer noch nichts mit den angesprochenen (und nicht von XP
>> herbeigef�hrten) Unversandt-Problemen zu tun.
> Mir gehts eigentlich nur um unversandte Nachrichten und wie deren
> Abgleich nach dem R�ckkopieren ins boxspezifische Verzeichnis
> mit dem <boX>.pp-File �ber die MID erfolgt. Lediglich darum.
Ach so, jetzt ist klar - wenn Du die MID per Filter patchst, wirst Du
diesbzgl. allerdings Probleme bekommen. Vermutlich wird das Ergebnis
sein, da� eine Nachricht mit gepatchter MID, die nicht versandt werden
konnte, von XP als versandt betrachtet werden wird.
Und zu der MID, die die unversandte Nachricht inzwischen tr�gt, wird XP
keine Nachricht in der Datenbank finden und mit einer Fehlermeldung
reagieren.
Stimmt, ist ein Szenario, mit dem man das Unversandt-Handling sabotieren
kann.
> Nach meinen Erfahrungen verschwinden Nachrichten dann, wenn
> sie nach dem R�ckkopieren nicht mehr als unversandt identifiziert
> werden, was bei mir an dem ge�nderten Domain-Tail der MID: lag.
> Ich bin dar�berhinaus nicht gerade ein Fan dieser Rumkopiererei,
Das hat UKA_PPP ja zwangsl�ufig schon immer gemacht (zumindest in eine
Richtung, aber nicht wieder zur�ck). Nur da� es fr�her selbst sogar
noch f�r die UUZ-Konvertierung zust�ndig war.
Sicher w�re es sch�ner, UKA_PPP w�rde direkt auf das XP-Spool zugreifen,
aber das k�me eben einem Umbau von UKA_PPP gleich.
>>> (mit ein paar netten Features zugegeben) und bin immer noch der
>>> Meinung, passender f�r eine Standard-Installation w�re vermutlich,
>>> das mal in ein UKA_PPP-Skript umzuschreiben sich damit auch
>>> komplett die Box- Daten aus der .bfg zu holen.
>> Genau das geht aber nicht, weil UKA_PPP - jedenfalls im derzeitigen
>> Zustand - Parameter wie den Boxnamen gar nicht auswertet und keine
>> Ahnung hat, wo die Spoolverzeichnisse von XP liegen.
>> Das w�re ein Totalumbau von UKA_PPP, den ich eigentlich nicht
>> vorhatte.
> Ich dachte eher an ein XP angepa�tes, erweitertes Installationsskript
> f�r eine Standardinstallation.
UKA_PPP m��te sich aber die Daten bei jedem Netcall neu holen. Nur bei
der Installation reicht nicht (und auch da w��te UKA_PPP ja erstmal
nicht, wo die BFGs l�gen, es sei denn, man h�lt sich an die Konvention
von RFC/Client und sagt einfach "eine Verzeichnisebene dar�ber").
Wobei mir gerade einf�llt, da� UKA_PPP mit einem $homedir arbeitet (was
wohl das XP-Verzeichnis ist), und ich grad nicht wei�, wo es das immer
�berhaupt hergehabt hat.
>> Eher hielte ich es noch f�r sinnvoll, sich mit dem Fixen von ein,
>> zwei alten Bugs in UKA_PPP zu besch�ftigen.
> Tja, sollte man vielleicht KHW wegen des Source mal anschreiben.
Ich denke nicht, da� er andere Sourcen hat als die, die wir auf dem FTP-
Server finden. Er hat mir mal geschrieben, da� er da dringend mal
aufr�umen m�sse, aber das ist schon ein paar Jahre her. ;)
>>> Ob man sich mit dem Batch und der Dokumentation wirklich
>>> neue und bleibende Verbesserungen schafft, wei� ich nicht.
>>> Ist vielleicht besser als vorher, aber unter einer Standard-
>>> Installation verstehe ich noch was anderes, als hinterher in
>>> .$cf und .$do herumzukramen.
>> Braucht man doch auch gar nicht. Gerade die User, die eine
>> Standard-Installation von UKA_PPP betreiben, brauchen �berhaupt gar
>> nix "herumzukramen". Das ist ja gerade das Sch�ne.
> Du mu�t doch den Kram erstmal einrichten.
> Im Prinzip sollte das Vorgehenen doch so sein, da� UKA_PPP
> ausgepackt wird und RFC/Client unter XP eingerichtet wird.
> Zus�tzlich w�re ein Konfigurationsskript erforderlich, da�
> diese Angaben f�r UKA - automatisch - �bernimmt.
> Vermutlich ist das mit einem Skript f�r X_Skript zu umst�ndlich,
> aber im Prinzip verstehe ich nur darunter eine Standard-Installation.
> Die f�hrt nicht unbedingt weiter zu der von Dir ausgew�hlten
> Batch-Anbindung. Insofern w�re vielleicht der Unterschied
> wichtig, was eine Standard-Installation aus XP und was eine
> aus UKA_PPP-Sicht w�re.
Ja gut, ich verstehe unter "Standard" im Moment die seit jeher von
UKA_PPP her bekannte Art der Installation.
Du sprichst eher von einer "richtigen" Anpassung an RFC/Client, aber die
hatte ich nicht im Blick.
> Nur wenn wir reden �ber eine Standard-Installation aus Sicht von
> XP reden, ist die mit UKAD derzeit besser gel�st.
Das ist klar, weil UKAD den Boxtyp direkt unterst�tzt. Nur geht z.B.
Multibox auch damit nicht.
Michael
------------------------------------------------------------------------
FreeXP Support-Mailingliste
[EMAIL PROTECTED]
http://www.freexp.de/cgi-bin/mailman/listinfo/support-list
