Newsgroup mit gleichem Namen auf verschiedenen Servern
Franz Moessl
Hallo zusammen,
ich habe eine Newsgroup, comp.lang.clarion, auf dem Server
news.individual.de und auf dem Server news.softvelocity.com.
Da diese beiden Server nicht Syncronisiert werden, möchte ich die
comp.lang.clarion von beiden Servern getrennt im Newsreeder anzeigen
lassen.
Der Hamster behandelt diese beiden Newsgroups aber nicht so, daß ich das
mit Opera 10 irgendwie hinkriegen würde.
Hat jemand eine Idee und kann mir weiterhelfen?
Danke!
Franz
--
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/
Heiko Rost
> ich habe eine Newsgroup, comp.lang.clarion, auf dem Server
> news.individual.de und auf dem Server news.softvelocity.com.
> Da diese beiden Server nicht Syncronisiert werden, m�chte ich die
> comp.lang.clarion von beiden Servern getrennt im Newsreeder anzeigen
> lassen.
> Der Hamster behandelt diese beiden Newsgroups aber nicht so, da� ich das
> mit Opera 10 irgendwie hinkriegen w�rde.
Das schaffst Du mit dem Hamster nicht. Da� die selben Gruppen von
mehreren Server abgefragt und dann als eine einzige angezeigt werden,
ist eine der Grundfunktionen des Hamsters. Wenn Du sie getrennt im
Newsreader haben willst, darfst Du nur einen Server mit dem Hamster
abfragen und mu�t den anderen in Opera als Server eintragen bzw. diese
Gruppe gar nicht �ber den Hamster beziehen.
Gru� Heiko
Franz Moessl
danke für den Tip. Das ist eine Idee!
Gruß
Franz
Am 11.11.2009, 15:03 Uhr, schrieb Heiko Rost <heiko...@gmx.de>:
> Am Wed, 11 Nov 2009 14:21:48 +0100 schrieb Franz Moessl:
>
>> ich habe eine Newsgroup, comp.lang.clarion, auf dem Server
>> news.individual.de und auf dem Server news.softvelocity.com.
>> Da diese beiden Server nicht Syncronisiert werden, möchte ich die
>> comp.lang.clarion von beiden Servern getrennt im Newsreeder anzeigen
>> lassen.
>> Der Hamster behandelt diese beiden Newsgroups aber nicht so, daß ich das
>> mit Opera 10 irgendwie hinkriegen würde.
>
> Das schaffst Du mit dem Hamster nicht. Daß die selben Gruppen von
> mehreren Server abgefragt und dann als eine einzige angezeigt werden,
> ist eine der Grundfunktionen des Hamsters. Wenn Du sie getrennt im
> Newsreader haben willst, darfst Du nur einen Server mit dem Hamster
> abfragen und mußt den anderen in Opera als Server eintragen bzw. diese
> Gruppe gar nicht über den Hamster beziehen.
>
> Gruß Heiko
Ulrich F. Heidenreich
>Am Wed, 11 Nov 2009 14:21:48 +0100 schrieb Franz Moessl:
>
>> ich habe eine Newsgroup, comp.lang.clarion, auf dem Server
>> news.individual.de und auf dem Server news.softvelocity.com.
>> Da diese beiden Server nicht Syncronisiert werden, möchte ich die
>> comp.lang.clarion von beiden Servern getrennt im Newsreeder anzeigen
>> lassen.
>> Der Hamster behandelt diese beiden Newsgroups aber nicht so, daß ich das
>> mit Opera 10 irgendwie hinkriegen würde.
>
>Das schaffst Du mit dem Hamster nicht.
Wirklich nicht? Ich könnte mir eine news.in.nntp-action vorstellen, die
die Newsgroupszeile je nach gepulltem Server in comp.lang.clarion.1 und
comp.lang.clarion.2 ändert. Oder hat der Hamster zu dem Zeitpunkt den
Artikel dafür schon zu tief in den Backen?
CU!
Ulrich
--
In 1 Monat und 14 Tagen ist Weihnachten
(Bin mal gespannt, was das Script am 25.12. macht)
http://invalid.de/spank-the-mugu.html
Stellt euch vor, es ist Mittwoch und keiner geht hin!
Hermann Hippen
> Heiko Rost in <news:hdejo2...@ID-23555.user.uni-berlin.de>:
>> Am Wed, 11 Nov 2009 14:21:48 +0100 schrieb Franz Moessl:
>>
>>> ich habe eine Newsgroup, comp.lang.clarion, auf dem Server
>>> news.individual.de und auf dem Server news.softvelocity.com.
>>> Da diese beiden Server nicht Syncronisiert werden, möchte ich die
>>> comp.lang.clarion von beiden Servern getrennt im Newsreeder anzeigen
>>> lassen.
>>> Der Hamster behandelt diese beiden Newsgroups aber nicht so, daß ich das
>>> mit Opera 10 irgendwie hinkriegen würde.
>>
>> Das schaffst Du mit dem Hamster nicht.
> Wirklich nicht? Ich könnte mir eine news.in.nntp-action vorstellen, die
> die Newsgroupszeile je nach gepulltem Server in comp.lang.clarion.1 und
> comp.lang.clarion.2 ändert.
Oder per Filter, je nach Server in anzulegende lokale NGs
comp.lang.clarion.individual/comp.lang.clarion.velocity,
kopieren/verschieben, die dann abboniert werden. So braucht man am
eigentlichen Posting nichts zu verändern.
--
To be is to do - Socrates
To do is to be - Sartre
Do Be Do Be Do - Sinatra
Heiko Rost
> Ulrich F. Heidenreich schrieb in h.d.n:
>> Wirklich nicht? Ich k�nnte mir eine news.in.nntp-action vorstellen, die
>> die Newsgroupszeile je nach gepulltem Server in comp.lang.clarion.1 und
>> comp.lang.clarion.2 �ndert.
>
> Oder per Filter, je nach Server in anzulegende lokale NGs
> comp.lang.clarion.individual/comp.lang.clarion.velocity,
> kopieren/verschieben, die dann abboniert werden. So braucht man am
> eigentlichen Posting nichts zu ver�ndern.
Und dann das ganze Gewusel wieder r�ckg�ngig machen, weil man in beide
Gruppen posten will und die Postings an den korrekten Server senden mu�?
Auch wenn das irgendwie funktionieren kann (weil der Datenbestand
beliebig manipulierbar ist), w�re das auf keinen Fall eine L�sung f�r
einen Neuling und alles andere als pflegeleicht.
Gru� Heiko
Hermann Hippen
> Am Wed, 11 Nov 2009 16:09:36 +0100 schrieb Hermann Hippen:
>> Ulrich F. Heidenreich schrieb in h.d.n:
>>> Wirklich nicht? Ich könnte mir eine news.in.nntp-action vorstellen, die
>>> die Newsgroupszeile je nach gepulltem Server in comp.lang.clarion.1 und
>>> comp.lang.clarion.2 ändert.
>>
>> Oder per Filter, je nach Server in anzulegende lokale NGs
>> comp.lang.clarion.individual/comp.lang.clarion.velocity,
>> kopieren/verschieben, die dann abboniert werden. So braucht man am
>> eigentlichen Posting nichts zu verändern.
> Und dann das ganze Gewusel wieder rückgängig machen, weil man in beide
> Gruppen posten will und die Postings an den korrekten Server senden muß?
Man muss nichts rückgängig machen. Das Versenden über den gewünschten
Server geht auch ganz einfach per Hamster Script. :)
> Auch wenn das irgendwie funktionieren kann (weil der Datenbestand
> beliebig manipulierbar ist), wäre das auf keinen Fall eine Lösung für
> einen Neuling und alles andere als pflegeleicht.
Wenn es einmal so installiert ist, bedarf es keiner Pflege. Was den
Hinweis 'Neuling' angeht: So kompliziert ist das nun wirklich nicht.
--
Wenn man etwas oft genug auseinander nimmt und wieder
zusammensetzt, hat man schließlich zwei davon.
Alfred Peters
> Ulrich F. Heidenreich schrieb in h.d.n:
>> Wirklich nicht? Ich k�nnte mir eine news.in.nntp-action vorstellen, die
>> die Newsgroupszeile je nach gepulltem Server in comp.lang.clarion.1 und
>> comp.lang.clarion.2 �ndert.
Theoretisch machbar.
> Oder per Filter, je nach Server in anzulegende lokale NGs
> ==========
> comp.lang.clarion.individual/comp.lang.clarion.velocity,
> kopieren/verschieben, die dann abboniert werden. So braucht man am
-v
Alfred
--
09859.9
Ulrich F. Heidenreich
[..]
>wäre das auf keinen Fall eine Lösung für
>einen Neuling und alles andere als pflegeleicht.
Full Ack. Nur meldete sich bei Deinem "Das schaffst Du mit dem Hamster
nicht" mein Dickkopf. Mit geeigneten Scripts bringt man dem auch noch
das Kaffeekochen bei ;-)
Hermann Hippen
> Es schrieb einmal Hermann Hippen:
>> Ulrich F. Heidenreich schrieb in h.d.n:
>>> Wirklich nicht? Ich könnte mir eine news.in.nntp-action vorstellen, die
>>> die Newsgroupszeile je nach gepulltem Server in comp.lang.clarion.1 und
>>> comp.lang.clarion.2 ändert.
> Theoretisch machbar.
>> Oder per Filter, je nach Server in anzulegende lokale NGs
>> ==========
>> comp.lang.clarion.individual/comp.lang.clarion.velocity,
>> kopieren/verschieben, die dann abboniert werden. So braucht man am
> -v
Meinte natürlich per Script in NewsIn Actions. Ist aber ja wie
irgendwie wie filtern :)
--
Überall gibt es fünf Elemente: Feuer, Wasser, Luft,
Erde und Stupidität.
Heiko Rost
> Man muss nichts r�ckg�ngig machen. Das Versenden �ber den gew�nschten
> Server geht auch ganz einfach per Hamster Script. :)
Wenn es lokale Gruppen sind, mu� noch einiges getan werden, weil die
Postings nicht in news.out liegen:
- die Postings sollten eine korrekte Message-Id haben
- das Skript mu� die eigenen Postings in den Gruppen suchen
- wissen, welche davon noch nicht weitergeleitet sind
- ggf. die Newsgroups-Zeile anpassen
- Das Posting als Datei in news.out ablegen
Das f�llt mir auf die Schnelle ein, wahrscheinlich kommt noch der eine
oder andere Punkt dazu, wenn man das versucht umzusetzen.
> Wenn es einmal so installiert ist, bedarf es keiner Pflege. Was den
> Hinweis 'Neuling' angeht: So kompliziert ist das nun wirklich nicht.
Kompliziert ist relativ. Irgendwann will man sicher andere Gruppen von
den Servern lesen und mu� das umkonfigurieren. Da den Durchblick
behalten, was an welchen Stellen ge�ndert werden mu�, verlangt meiner
Meinung nach einiges an Wissen �ber die Abl�ufe und Erfahrung.
Gru� Heiko
Ulrich F. Heidenreich
>Es schrieb einmal Hermann Hippen:
>> Ulrich F. Heidenreich schrieb in h.d.n:
>
>>> Wirklich nicht? Ich könnte mir eine news.in.nntp-action vorstellen, die
>>> die Newsgroupszeile je nach gepulltem Server in comp.lang.clarion.1 und
>>> comp.lang.clarion.2 ändert.
>
>Theoretisch machbar.
Wird aber praktisch - wie Heiko so richtig bemerkte - haarig, wenn man
auch in die Gruppe posten will. Grundsätzlich ist Franz's Ansinnen so
hamsteratypisch, daß dabei einklich nichts Vernünftiges bei rumkommen
kann :^)
>> Oder per Filter, je nach Server in anzulegende lokale NGs
>> ==========
>> comp.lang.clarion.individual/comp.lang.clarion.velocity,
>> kopieren/verschieben, die dann abboniert werden. So braucht man am
>
>-v
AOL.
Hermann Hippen
> Kompliziert ist relativ.
Stimmt. Aber:
> Das schaffst Du mit dem Hamster nicht.
ist halt nicht ganz richtig. Es gäbe da eben schon Möglichkeiten. :)
--
Alle unbeseelten Gegenstände können sich gerade soweit
bewegen, dass sie einem im Weg sind.
Wolfgang Jäth
>
>> Kompliziert ist relativ.
>
> Stimmt. Aber:
>
>> Das schaffst Du mit dem Hamster nicht.
>
Die wï¿œrde ich aber weniger als /Mï¿œglichkeit/ denn als irgendwas zwischen
durchs-Knie-ins-Auge und Vergewaltigung bezeichnen. <duck>
Die einfachste Lï¿œsung fï¿œr die Frage des OP ist in der Tat, eine (oder
beide) der Gruppen gar nicht ï¿œber den Hamster, sondern direkt im Client
abzufragen.
Wolfgang
--
Hermann Hippen
> Hermann Hippen schrieb:
>>
>>> Kompliziert ist relativ.
>>
>> Stimmt. Aber:
>>
>>> Das schaffst Du mit dem Hamster nicht.
>>
>> ist halt nicht ganz richtig. Es gäbe da eben schon Möglichkeiten. :)
> Die würde ich aber weniger als /Möglichkeit/ denn als irgendwas zwischen
> durchs-Knie-ins-Auge und Vergewaltigung bezeichnen. <duck>
> Die einfachste Lösung für die Frage des OP ist in der Tat, eine (oder
> beide) der Gruppen gar nicht über den Hamster, sondern direkt im Client
> abzufragen.
Natürlich: FACK
--
Die Zukunft ist auch nicht mehr das, was sie mal war.
Ulrich F. Heidenreich
>Die einfachste Lösung für die Frage des OP ist in der Tat, eine (oder
>beide) der Gruppen gar nicht über den Hamster, sondern direkt im Client
>abzufragen.
Und was brächte ihm das: Wie sollte der Client es unterscheiden können,
von welchen Server (Hamster oder "externem") er die Inhalte bezog?
CU!
Ulrich
--
In 1 Monat und 13 Tagen ist Weihnachten
(Bin mal gespannt, was das Script am 25.12. macht)
http://invalid.de/spank-the-mugu.html
Stellt euch vor, es ist Donnerstag und keiner geht hin!
Hermann Hippen
> Wolfgang Jäth in <news:hdgj4a...@ID-4636.user.dfncis.de>:
>> Die einfachste Lösung für die Frage des OP ist in der Tat, eine (oder
>> beide) der Gruppen gar nicht über den Hamster, sondern direkt im Client
>> abzufragen.
> Und was brächte ihm das: Wie sollte der Client es unterscheiden können,
> von welchen Server (Hamster oder "externem") er die Inhalte bezog?
Du abbonierst doch die Gruppe zweimal, einmal vom Hamster und einmal
vom externen Server und hast so die Gruppe doch auch zweimal im
Client. Jedenfalls funktioniert es mit Dialog so (Anzeige in der NG
Liste: Gruppenname(Server)) und wenn ich mich schwach erinnere,
doch auch mit Agent?
--
Wenn ein Experiment gelingt,
dann ist vorher etwas schiefgegangen.
Ulrich F. Heidenreich
>Ulrich F. Heidenreich schrieb in h.d.n:
>
>> Wolfgang Jäth in <news:hdgj4a...@ID-4636.user.dfncis.de>:
>
>>> Die einfachste Lösung für die Frage des OP ist in der Tat, eine (oder
>>> beide) der Gruppen gar nicht über den Hamster, sondern direkt im Client
>>> abzufragen.
>
>> Und was brächte ihm das: Wie sollte der Client es unterscheiden können,
>> von welchen Server (Hamster oder "externem") er die Inhalte bezog?
>
>Du abbonierst doch die Gruppe zweimal, einmal vom Hamster und einmal
>vom externen Server und hast so die Gruppe doch auch zweimal im
>Client.
Meinem Agent kann ich nur sagen, daß er entweder vom Hamster oder vom
externen Server saugen kann. Und dann benimmt er sich RfC-1036-konform:
|5.5. Newsgroups
|
|The Newsgroups header's content specifies which newsgroup(s) the article
|is posted to
CU!
Ulrich
--
In 1 Monat und 12 Tagen ist Weihnachten
(Bin mal gespannt, was das Script am 25.12. macht)
http://invalid.de/spank-the-mugu.html
Stellt euch vor, es ist Freitag und keiner geht hin!
Heiko Rost
> Meinem Agent kann ich nur sagen, da� er entweder vom Hamster oder vom
> externen Server saugen kann.
Es gibt Newsreader, bei denen man mehrere Server eintragen und von jedem
dieser Server die selbe Gruppe abonnieren kann. Dann sieht man diese
Gruppe auch mehrmals im Newsreader.
Gru� Heiko
Ulrich F. Heidenreich
>Am Fri, 13 Nov 2009 10:53:05 +0100 schrieb Ulrich F. Heidenreich:
>
>> Meinem Agent kann ich nur sagen, daß er entweder vom Hamster oder vom
>> externen Server saugen kann.
>
>Es gibt Newsreader, bei denen man mehrere Server eintragen und von jedem
>dieser Server die selbe Gruppe abonnieren kann. Dann sieht man diese
>Gruppe auch mehrmals im Newsreader.
Ein Schwachsinn, der erst durch durch den Hamster behoben wurde. :^)
Manfred Polak
>Am Fri, 13 Nov 2009 10:53:05 +0100 schrieb Ulrich F. Heidenreich:
>
>> Meinem Agent kann ich nur sagen, da� er entweder vom Hamster oder vom
>> externen Server saugen kann.
>
>Es gibt Newsreader, bei denen man mehrere Server eintragen und von jedem
>dieser Server die selbe Gruppe abonnieren kann.
Z.B. Agent seit Jahren (aber Ulrich ist hier Traditionalist).
>Dann sieht man diese Gruppe auch mehrmals im Newsreader.
Echt? Ich finde dieses Verhalten absurd. Newsgroups sollten durch
ihren Namen eigentlich eindeutig gekennzeichnet sein, so dass es
eben jeweils nur *eine* Gruppe mit einem bestimmten Namen geben
kann. Jedenfalls in Hierarchien, die einigerma�en allgemein anerkannt
sind. Und dann sollten auch alle Postings einer Gruppe zusammen
angezeigt werden, egal, von welchem Server sie kommen. Es gibt
tats�chlich Newsreader, die das nicht tun? Agent zum Gl�ck schon.
Die Ausgangssituation dieses Threads ist ohnehin ein Unding. comp.*
geh�rt zu den Big 8 (ist also allgemein *sehr* anerkannt), und
news.individual.de ist bekanntlich sehr gut ins internationale Peering
eingebunden. Wenn also tats�chlich comp.lang.clarion zwischen
news.individual.de und news.softvelocity.com nicht "synchronisiert"
wird, wie Franz schrieb, wenn es also letzlich zwei verschiedene
Gruppen mit demselben Namen gibt, dann haben m�glicherweise
die Betreiber von news.softvelocity.com ein ernstes Problem (oder
sie sind selbst das Problem). Vielleicht sollte man sie mal tret^W
kontaktieren, statt hier nach komplizierten L�sungen zu suchen.
Manfred
Heiko Rost
> Heiko Rost schrieb:
>
>>Es gibt Newsreader, bei denen man mehrere Server eintragen und von jedem
>>dieser Server die selbe Gruppe abonnieren kann.
>
> Z.B. Agent seit Jahren (aber Ulrich ist hier Traditionalist).
Besser als der 1.93 sind die neuen Versionen f�r mich nicht, das ist
aber ein anderes Thema.
>>Dann sieht man diese Gruppe auch mehrmals im Newsreader.
>
> Echt? Ich finde dieses Verhalten absurd.
Das ist in meinen Augen auch absurd, trotzdem machen es die Newsreader.
Mir f�llt keiner ein, der Gruppen von mehreren Servern zusammenfassen
kann. Allerdings mu�te ich wegen dem Hamster auch nicht so genau auf
diese Funktion achten.
> Die Ausgangssituation dieses Threads ist ohnehin ein Unding. comp.*
> geh�rt zu den Big 8 (ist also allgemein *sehr* anerkannt), und
> news.individual.de ist bekanntlich sehr gut ins internationale Peering
> eingebunden. Wenn also tats�chlich comp.lang.clarion zwischen
> news.individual.de und news.softvelocity.com nicht "synchronisiert"
> wird, wie Franz schrieb, wenn es also letzlich zwei verschiedene
> Gruppen mit demselben Namen gibt, dann haben m�glicherweise
> die Betreiber von news.softvelocity.com ein ernstes Problem (oder
> sie sind selbst das Problem).
Wahrscheinlich leztzeres, ich tippe darauf, da� die kein Peering wollen.
Von den zwei Dutzend Gruppen, die mir angezeigt werden (m�glicherweise
sind es nach Anmeldung mehr) ist nur eine aus den Big8, der Rest sieht
mit nach lokalen aus.
Gru� Heiko
Wilfried Kramer
> Am Fri, 13 Nov 2009 23:49:49 +0100 schrieb Manfred Polak:
>> Heiko Rost schrieb:
>>> Dann sieht man diese Gruppe auch mehrmals im Newsreader.
>> Echt? Ich finde dieses Verhalten absurd.
>
> Das ist in meinen Augen auch absurd, trotzdem machen es die Newsreader.
> Mir f�llt keiner ein, der Gruppen von mehreren Servern zusammenfassen
> kann.
Laut glaubw�rdiger Aussagen mehrerer Quellen sollen aktuelle Agenten
genau das k�nnen bzw. tun.
Wilfried
--
Ein Vergleich ist kein Vergleich, wenn er nicht hinkt.
D.J. in <news:1forodrx...@syneticon.de>
Wolfgang Jäth
>
>>>> Dann sieht man diese Gruppe auch mehrmals im Newsreader.
>>> Echt? Ich finde dieses Verhalten absurd.
>> Das ist in meinen Augen auch absurd, trotzdem machen es die Newsreader.
>> kann.
>
> Laut glaubwï¿œrdiger Aussagen mehrerer Quellen sollen aktuelle Agenten
> genau das kï¿œnnen bzw. tun.
Wï¿œrde mich mal interessieren, welche (Agenten, nicht Quellen <g>)? Ich
kann fￜr OE und Thunderbird definitiv sagen, daￜ sie das nicht kￜnnen.
Wolfgang
--
Hermann Hippen
> Wilfried Kramer schrieb:
>>
>>>>> Dann sieht man diese Gruppe auch mehrmals im Newsreader.
>>>> Echt? Ich finde dieses Verhalten absurd.
>>> Das ist in meinen Augen auch absurd, trotzdem machen es die Newsreader.
>>> Mir fällt keiner ein, der Gruppen von mehreren Servern zusammenfassen
>>> kann.
>>
>> Laut glaubwürdiger Aussagen mehrerer Quellen sollen aktuelle Agenten
>> genau das können bzw. tun.
> Würde mich mal interessieren, welche (Agenten, nicht Quellen <g>)? Ich
> kann für OE und Thunderbird definitiv sagen, daß sie das nicht können.
Mit Agent war wohl Forte Agent gemeint.
--
Ärzte können ihre Fehler begraben,
aber ein Architekt kann dir nur raten, Efeu zu pflanzen.
Wolfgang Jäth
>
> Mit Agent war wohl Forte Agent gemeint.
Ach so; hab ich wohl missinterpretiert (manchmal meinen die Leute damit
auch einfach nur allgemein Clients).
Wolfgang
--
Wilfried Kramer
Grunds�tzlich richtig.
Aber direkt vor meiner Antwort ging es gerade um Ulrichs Fort� Agent,
der genauso alt wie meiner ist.
Wilfried
--
Erz�hl mir nichts �ber Zuf�lle, ich verdiene mein Geld in der EDV-Branche.
Zuf�lle gibt es nicht, diese Kisten sind einfach nur hochintelligent, b�se
und hinterh�ltig. [Ralph J.Mayer in hdm]
Heiko Studt
> >> Wirklich nicht? Ich könnte mir eine news.in.nntp-action vorstellen, die
> >> die Newsgroupszeile je nach gepulltem Server in comp.lang.clarion.1 und
> >> comp.lang.clarion.2 ändert.
> Theoretisch machbar.
Wirklich?
Die Artikel wandern doch auch in die History.
Eine Mid-Änderung ist ein NO-NO!
Daher werden die Artikel genau einmal geholt - entweder von individual
oder dem anderen.
Sinnvoll wäre es
a) Serveradmins treten untereinander nen direkten feed to etablieren
b) Wenn das nicht geht die Artikel zu markieren. Im Client muss dann
noch bei Antworten ein Header gesetzt werden -> damit geht es raus.
MFG
Heiko Studt
--
www.bash.org #205970
does anyone here have a computer?
Alfred Peters
> Am 11.11.2009 schrieb Alfred Peters:
>
>>>> die Newsgroupszeile je nach gepulltem Server in comp.lang.clarion.1 und
>> Theoretisch machbar.
> Wirklich?
Jap. Ich w�rde die Speicherung in einer Gruppe bevorzugen, sonst treten
weitere Probleme wegen des falschen Gruppennamens auf.
> Die Artikel wandern doch auch in die History.
> Eine Mid-�nderung ist ein NO-NO!
Im Gegenteil. Ich denke dabei an das Verfahren, das bei CopyIf angewandt
wird, um die /eigenen/ Threads in einer Gruppe zu sammeln. Also je nach
Quellserver ein bestimmter Zusatz in die MID einbauen. Bei den Antworten
scannt man den References-Header, um den Artikel an den richtigen Server
weiter zu leiten. Der References-Header muss dann nat�rlich wieder
berichtigt werden.
> Daher werden die Artikel genau einmal geholt - entweder von individual
> oder dem anderen.
Nach obiger Prozedur - kein Thema. Davon abgesehen, f�hren die Server
grade nicht die selben Artikel.
Alfred
--
09899.1
Ulrich F. Heidenreich
>Am 11.11.2009 schrieb Alfred Peters:
>
>> >> Wirklich nicht? Ich könnte mir eine news.in.nntp-action vorstellen, die
>> >> die Newsgroupszeile je nach gepulltem Server in comp.lang.clarion.1 und
>> >> comp.lang.clarion.2 ändert.
>> Theoretisch machbar.
>
>Wirklich?
>Die Artikel wandern doch auch in die History.
[..]
>Daher werden die Artikel genau einmal geholt - entweder von individual
>oder dem anderen.
Das passt im vorliegenden Fall doch auch, weil das ganze Konstrukt
wegen zwei "nichtsynchroner" Server gewünscht war. Deswegen hat der
eine Server Artikel, die individual nicht hat und umgekehrt. Der
OP hätte sie - aus welchen mir nicht nachvollziehbaren Gründen auch
immer - ja gerne getrennt.
CU!
Ulrich
--
In 0 Monat und 31 Tagen ist Weihnachten
(Bin mal gespannt, was das Script am 25.12. macht)
http://invalid.de/spank-the-mugu.html
Heiko Studt
> > Die Artikel wandern doch auch in die History.
> > Eine Mid-Änderung ist ein NO-NO!
> Im Gegenteil. Ich denke dabei an das Verfahren, das bei CopyIf angewandt
> wird, um die /eigenen/ Threads in einer Gruppe zu sammeln. Also je nach
Dabei wird die MID AFAIR nicht geändert, sondern Hamster-Interne
"import"-Funktionen gnutzt, die die History ignorieren.
Aber von externen Servern jeweils alles in die jeweilige spezielle
Gruppe zu bringen müsste man das pullen ausserhalb Hamsters machen
(denn sonst lädt er nicht weil MID vorhanden). Dann braucht man keinen
Hamster mehr.
Alfred Peters
>
>>> Die Artikel wandern doch auch in die History.
>> Im Gegenteil. Ich denke dabei an das Verfahren, das bei CopyIf angewandt
>> wird, um die /eigenen/ Threads in einer Gruppe zu sammeln. Also je nach
>
Ich denke schon: <f7bmo...@news.tglsoft.de> *g*
> sondern Hamster-Interne
> "import"-Funktionen gnutzt, die die History ignorieren.
Hier werden die Artikel eh nur einmal gespeichert.
Aber mit History da das Script die MID ver�ndert, muss es auch �berpr�fen,
ob der Artikel schon da ist.
> Aber von externen Servern jeweils alles in die jeweilige spezielle
Nein, eine Gruppe mit dem originalen Namen.
> Gruppe zu bringen m�sste man das pullen ausserhalb Hamsters machen
<Ho�cker> Wieso das denn?
> (denn sonst l�dt er nicht weil MID vorhanden).
Huh? Die originalen MIDs landen doch *nie* im Hamster.
Alfred
--
09901.1
Heiko Studt
> >Daher werden die Artikel genau einmal geholt - entweder von individual
> >oder dem anderen.
> Das passt im vorliegenden Fall doch auch, weil das ganze Konstrukt
> wegen zwei "nichtsynchroner" Server gewünscht war. Deswegen hat der
> eine Server Artikel, die individual nicht hat und umgekehrt. Der
> OP hätte sie - aus welchen mir nicht nachvollziehbaren Gründen auch
> immer - ja gerne getrennt.
Sind die Artikel der beiden Server XOR?
Ich bin von OR ausgegangen, wobei man wissen will, von welchem Server
denn nun spezielle Artikel kommen, damit man an den richtigen Server
antworten kann.
Der Sinn dahinter verschliesst sich auch mir - NNTP bzw Usenet ist für
Inseln nicht ausgelegt.
Ulrich F. Heidenreich
>Am 26.11.2009 schrieb Ulrich F. Heidenreich:
>
>> >Daher werden die Artikel genau einmal geholt - entweder von individual
>> >oder dem anderen.
>
>> Das passt im vorliegenden Fall doch auch, weil das ganze Konstrukt
>> wegen zwei "nichtsynchroner" Server gewünscht war. Deswegen hat der
>> eine Server Artikel, die individual nicht hat und umgekehrt. Der
>> OP hätte sie - aus welchen mir nicht nachvollziehbaren Gründen auch
>> immer - ja gerne getrennt.
>
>Sind die Artikel der beiden Server XOR?
s/die/wohl einige/
Und nur für jene bekäme es einen Sinn.
>Ich bin von OR ausgegangen, wobei man wissen will, von welchem Server
>denn nun spezielle Artikel kommen, damit man an den richtigen Server
>antworten kann.
Und für die Artikel, die auf beiden liegen, ist es auch egal, auf
welchem der beiden Server man antwortet.
>Der Sinn dahinter verschliesst sich auch mir - NNTP bzw Usenet ist für
>Inseln nicht ausgelegt.
Das sowieso.
CU!
Ulrich
--
In 0 Monaten und 30 Tagen ist Weihnachten
(Bin mal gespannt, was das Script am 25.12. macht)
http://invalid.de/spank-the-mugu.html
Heiko Studt
> Ich denke schon: <f7bmo...@news.tglsoft.de> *g*
Google groups kennt die MID net...aber wozu habe ich GoldFind? ;-)
> > sondern Hamster-Interne
> > "import"-Funktionen gnutzt, die die History ignorieren.
> Hier werden die Artikel eh nur einmal gespeichert.
Eh, Du bist Dir vermutlich sicher. Vermutlich trügt meine Erinnerung,
dass man eine MID mehrfach löschen muss, bis ihr Vorkommen für alle
Gruppen entfernt ist.
> > Gruppe zu bringen müsste man das pullen ausserhalb Hamsters machen
> <Hoëcker> Wieso das denn?
Siehe Begründung. ;-)
> > (denn sonst lädt er nicht weil MID vorhanden).
> Huh? Die originalen MIDs landen doch *nie* im Hamster.
Wenn Du Copyif bzw ähnliches Verfahren nutzt - doch.
Copyif/CopyFups läuft so:
* Postings werden geladen
* Postings werden durchgegangen und kopiert(!)
Bei Punkt 1 "versagt" Hamster dann, wenn zwei mal der selbe Artikel
reinkommen soll von verschiedenen Servern. Naja, eigentlich macht er
dann genau das, was "man" von ihm erwartet... :>
Alfred Peters
>> Hier werden die Artikel eh nur einmal gespeichert.
> Eh, Du bist Dir vermutlich sicher. Vermutlich tr�gt meine Erinnerung,
> dass man eine MID mehrfach l�schen muss, bis ihr Vorkommen f�r alle
> Gruppen entfernt ist.
Das kommt ganz darauf an, welche L�schfunktion man benutzt.
>>> (denn sonst l�dt er nicht weil MID vorhanden).
>> Huh? Die originalen MIDs landen doch *nie* im Hamster.
>
> Wenn Du Copyif bzw �hnliches Verfahren nutzt - doch.
> Copyif/CopyFups l�uft so:
Nein, Missverst�ndnis.
|>> Wirklich nicht? Ich k�nnte mir eine news.in.nntp-action vorstellen, die
|>> ...
| Theoretisch machbar.
Ich bezog mich *nur* auf die Manipulation der MID. Die Ver�nderung soll
jedoch bereits in der Aktion "news.in" passieren. Dadurch landet die
originale MID gar nicht erst in der History.
Alfred
--
09903.3
Heiko Studt
> >Sind die Artikel der beiden Server XOR?
> s/die/wohl einige/
Also OR.
> Und nur für jene bekäme es einen Sinn.
Naja - ich verstehe nicht, wie das Feeding so kaputt sein kann, dass nur
ein Teil der Artikel auf beiden Servern landet. Entweder ist der eine
kaputt (er sendet nicht) oder der andere sendet nicht. Aber dass beide
dieses Problem haben, dass ist wirklich crappy. Artikel, die beide haben,
müssten also von einem dritten Server stammen - warum nutzt Du nicht den
zum pushen Deiner Artikel? Dann bekommt jeder (auf beiden kaputten
Server wie auch im Usenet) die Artikel zu sehen...
> Und für die Artikel, die auf beiden liegen, ist es auch egal, auf
> welchem der beiden Server man antwortet.
Nein, gerade nicht. Wenn der Feed so kaputt ist, dass es Artikel gibt,
die nur auf einem liegen (also Inselsituation), kommen alle Antworten an
diesen Server auch auf die Insel - und Leute des anderen Servers
bekommen sie nicht.
Heiko Studt
> >> Hier werden die Artikel eh nur einmal gespeichert.
> > Eh, Du bist Dir vermutlich sicher. Vermutlich trügt meine Erinnerung,
> > dass man eine MID mehrfach löschen muss, bis ihr Vorkommen für alle
> > Gruppen entfernt ist.
> Das kommt ganz darauf an, welche Löschfunktion man benutzt.
Die andere ist soooo neu! Die kennt doch noch gar keiner! ;-)
> Ich bezog mich *nur* auf die Manipulation der MID. Die Veränderung soll
> jedoch bereits in der Aktion "news.in" passieren. Dadurch landet die
> originale MID gar nicht erst in der History.
Mmmh, da müsste ich in den Source schauen, denn ich kann mir es nicht
vorstellen, da dies die Wahrscheinlichkeit von doppeltem Laden sehr
stark erhöht. Andererseits muss ich zugeben, mich nie dafür interessiert
zu haben... *duck*
Ulrich F. Heidenreich
>Am 27.11.2009 schrieb Ulrich F. Heidenreich:
>> Und für die Artikel, die auf beiden liegen, ist es auch egal, auf
~~~~~~(!)
>> welchem der beiden Server man antwortet.
>
>Nein, gerade nicht. Wenn der Feed so kaputt ist, dass es Artikel gibt,
>die nur auf einem liegen (also Inselsituation), kommen alle Antworten an
~~~~~(!)
>diesen Server auch auf die Insel
Vielleicht wollte der OP genau das erreichen? Nämlich unterscheiden zu
können, welche Artikel von der Insel kommen und welche aus dem Usenet,
um adäquat antworten zu können ...
CU!
Ulrich