Hi Andreas,
> > > Die Tariftabelle von Viag enthielt am Ende den Eintrag (Michael, h�rst Du zu?)
> > Immer. Auch wenn du�s nicht erwartest...
>
> M*** dann mu� ich ab jetzt mit meinen Worten vorsichtiger umgehen ;-)
H�tte ich mich doch nicht verraten!
> Eben wird mir alles klar - Sorry, Michael!
>
> isdnlog macht zuerst einen
>
> getZone()
>
> und nur, wenn der UNKNOWN zur�ckliefert, geht isdnlog in die
> Verzonungstabelle.
>
> Dadurch wollte ich erreichen, das die "rate-xx.dat" immer Vorrang hat,
> resp. man via "rate-xx.dat" die Verzonungstabelle �bersteuern kann
> (was bei vielen Lokalen Carriern durchaus Sinn macht)
>
> Das funktioniert nat�rlich nur so lange, wie es keinen "letzten Eintrag"
> in der "rate-xx.dat" gibt, der auf alles matched.
>
> Dumme Situation ... wie wollen wir das besser machen?
> (�h, Alexander: K�nnte das nicht auch Dein Problem sein, von dem
> Du seit Tagen schreibst?)
Ich plane das eh etwas anders. Irgendwo wird festgestellt, da� die
Rufnummer im Inland liegt, und erst dann wird die Verzonungstabelle
befragt. Trotzdem k�nnte ein A:-Tag das �bersteuern.
> 1. Per heute alle "A:+" Eintr�ge aus der "rate-xx.dat" raus
> 2. Darauf warten, da� Leo die Verzonungstabellen-Geschichte
> fertigstellt.
> 3. Ab dann alle Inlands-Vorwahlen aus der "rate-xx.dat" raus, und
> in Verzonungstabellen rein
> 4. Dann Vorrangordnung:
> 1. Verzonungstabelle
> 2. getRate()
>
> Einverstanden?
Nicht ganz. In der rate-xx.dat stehen wesentlich weniger
Inlandsvorwahlen, und diese sind auch leichter editierbar (vor allem f�r
den Normaluser). Also sollte man mit entsprechenden A;-Eintr�gen
durchaus die Verzonungstabelle �bersteuern k�nnen (und seis nur, um
kurzfristig einen Fehler in der Verzonung zu patchen).
Ich bin daf�r:
A:+ bleiben drinnen (wie sonst willst du ein "restliche Welt" abbilden?)
A:+49 kommen dazu (schadet nix)
Ein A:-Tag habt Vorrang vor der Verzonungstabelle, wenn es in mehr
Stellen �bereinstimmt als die Landesvorwahl.
d.h.
A:+ -> Verzonungstabelle -> wenn nix gefunden -> A:-Tag
A:+49 -> Verzonungstabelle -> wenn nix gefunden -> A:-Tag
A:+494711 -> A:-Tag
letzter Fall sollte eigentlich nicht vorkommen, aber wenn doch, sollte
er so verarbeitet werden.
> > Da mu� ich dir widersprechen: Tarifwechsel kommen nach dem �=�, vor dem
> > �/� k�nnen Listen von Tagen, nach dem �/� und vor dem �=� Listen von
> > Stunden angegeben werden. Zumindest wollte ich sowas programmieren. (Ihr
> > wisst ja: das Programm macht was du _schreibst_, und nicht was du
> > _willst_)
>
> Dann m�chte ich Dich bitten, mal zu pr�fen, was Du _geschrieben_ hast.
> Das "rate.c" sowas kann, ist mir neu (oder ich habe es wieder vergessen).
> Bitte poste doch hier ein sch�nes Syntax-Diagramm, oder noch
> besser: Korrigiere meine Syntax-Beschreibung im README von isdnlog.
Syntax-Diagramm? Ach, du meinst diese Landkarte!
Aber ich verstehe dein Problem nicht. Auszug aus _deinem_ README:
-----------------------
T:Tag/Zeit=Kosten[,Kosten] Name
wobei Tag in der Form 1-5 oder 1,2,3,4,5 stehen kann, 1=Montag, es gibt
noch * fuer alle Tage und H fuer Holiday=Feiertag sowie
W=Werktag (entspricht 1-5) sowie E=Weekend (entspricht 6-7)
Welcher Tag ein Holiday (Tag mit verguenstigen Tarifen) ist, entnimmt
isdnlog der Datei "holiday-xx.dat" (Mit "xx" fuer das Land, in dem sich
isdnlog befindet). Auch diese Datei muss ueber den Eintrag
[...]
die Zeit sieht aehnlich aus, 8-12 oder 8,9,10,11 oder 8-12,13-17
ACHTUNG: 8-12 bedeutet 8:00 bis 11:59 !!!
-------------------
bye, Michi
--
netWorks Vox: +43 316 698260
Michael Reinelt Fax: +43 316 692343
Geisslergasse 4 GSM: +43 676 3079941
A-8045 Graz, Austria e-mail: [EMAIL PROTECTED]
_______________________________________________
Rates4linux-devel mailing list
[EMAIL PROTECTED]
http://lists.SourceForge.net/mailman/listinfo/rates4linux-devel
