Hi All,
-----Original Message-----
From: Michael Reinelt <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Freitag, 24. September 1999 08:09
Subject: Re: Zusammenfassung - destination.c
>Hi alle,
>
>Vorab m�chte ich noch folgendes bemerken: Unser neuer Schl�ssel (TLD)
>ist nach aussen hin eigentlich kaum sichtbar. ...
Stimmt
>Die Frage ist noch, wie wir die Eingabedateien f�r den Preprozessor
>strukturieren. Ene gewisse struktur h�tte ich schon gerne.
rate-CC.dat hat genug Struktur ;-)
>In Deutschland existiert ja f�r jeden Provider eine eigene Datei, die
>dann mehr oder weniger zusammenkopiert werden, und dann die rate-de.dat
>ergeben. Dieses Zusammenkopieren k�nnte dann ja der Preprozessor
>�bernehmen.
Der Preprozessor koennte auch ueber die Einzelteile laufen ist egal. Raus
kommt wieder eine rate.dat mit TLDs statt Laendernamen.
Ich moechte wenn ein Alias noch nicht bekannt ist, diesen in country-de.dat
aufnehmen, damit er eben beim naechsten mal keine Troubles mehr macht.
Das Problem ist dann nur das Synchronisieren der verschieden country-de.dat
Versionen.
>In �sterreich wird die rate-at.dat von einem C-Programm erzeugt. Das
>m�chte ich eigentlich so beibehalten (oder, Leo?) ...
Ist jetzt ziemlich praktisch, weil viel Tippslerei wegfaellt, wird aber ein
Problem sobald der neue rate.c Syntax zuschlaegt z.b.
T:[01.01.2000]*/*=...
bei einzelnen Tarifen.
Ich glaub mittelfristig wird das rate-at.c nur mehr zum Produzieren eines
neuen Providers bzw. bei grossen Aenderungen verwendet. kleinere Aenderungen
wie Tarifanpassung in ein paar Zonen gehen dann direkt einfacher. Und die
deutsche Wartungsvariante mit getrennten rate-provider.dat hat doch einige
Vorteile.
>... Sch�n w�re es, wenn
>sich der Preprozessor in dieses C-Programm einh�ngen lie�e.
KISS sagt er immer, da reicht eine Shell-Skript.
>...Nachdem der
>Preprozessor Perl ist, wird es kein einfaches API geben. Aber �ber ein
>paar system()-Aufrufe m�sste sich das schon machen lassen, oder? Leo,
>denk mal dar�ber nach.
Wie gesagt - der Praeprozessor bleibt ein eigenstaendiges (interaktives)
Programm mit ein paar Befehlen:
j ... Eintrag ist ok
n ... Eintrag ignorieren
/ text ... grepe country-de.dat nach text
=text ... uebernehme text und appende in country als Alias
+text ... haenge text an und versuch nochmals zu matchen
text ...versuch nochmals zu matchen mit text
Der Prompt kommt immer bei wld>1.
Weiters ist natuerlich eine batch-Variante moeglich, wo Problemfaelle
(wld>0) in ein Log geschrieben werden.
>Jochen wollte eine Flughafenliste auftreiben. Wir schauen uns die mal
>an, dann reden wir weiter.
D'accord
>> >Grunds�tzlich finde ich die Idee immer besser, die Destinationsdatenbank
>> >in eine internationalen Teil (Vorwahl zu Landes-, Gebiets- oder
>> >Staedtecode) und einen nationalen Teil (Landescode zu Landesnamen,
>> >verschiedene Schreibweisen, regionale Ortsnamen) aufzuteilen.
>>
>> Effizienter waere es alles in einer Datenbank zu halten. Sind ca. 0.5 MB
>> (grob geschaetzt), de/code hat ca. 90 K.
>
>Wie du das technisch realisierst, ist mir eigentlich schnuppe. Ich
>m�chte nur erreichen, da� sich der sprachabh�ngige Teil leicht
>austauschen l�sst, und der sprachunabh�ngige Teil nicht mehrmals
>vorkommt, um die Daten im CVS nicht aufzublasen.
Der sprachunabh�ngige Teil ist sicher der kleinere Teil des ganzen, die
Laender +Codes sind dzt 400 oder so Zeilen, das ist kein Kilobyte.
Ist fast das selbe Problem wie mit den Verzonungstabelle. Eigentlich sollte
wir nur die Rohdaten mitliefern, das Erzeugen der gdbm's sollte im make bei
der Installation erfolgen, da braeuchten wir auch die zone-gdbm's nicht im
CVS halten (und BTW das makefile kann's eh [make zonefiles], muesste nur in
den uebergeordneten make-Aufruf eingebunden werden.)
Voila 1.2 Meg eingespart.
Von dem abgesehen, die ganzen areacode und vorwahl.dat Relikte sind auch
noch im CVS oder irre ich da:
cvs ... update -dP sollte mich doch von solchem Ballast befreien oder??
>> >* eine Funktion, die �berpr�ft, ob und wie gut eine Telefonnummer mit
>> >einem destionation-Code �bereinstimmt (zur Auswertung der A:-Tags)
>
>> Falls kein +nnn passt fragst du getDestination(Nummer) und bekommst
>> Landescode und Stadt retour.
>> Dann suchst du in der Providertabelle (binaer) nach der Stadt und wenn
nix
>> nach dem Land. Also in der Hierarchie wieder von unten (laengste Nummer)
>> nach oben (kuerzeste Nummer).
>
>Schon klar, aber diese Funktionalit�t w�rde ich gerne ins destination.c
>verlagern, so habe ich das gemeint.
Ist der falsche Platz fuer sowas. Das sollte auf jeden Fall in rate.c
bleiben. Hat auch nix mit der Funktionalitaet von destination.c zu tun
sondern ist eine spezielle Funktion, die eben nur getRate braucht.
Destination muesste dann deine struct Area kennen um einen Match zu finden -
wie gesagt - passt ueberhaupt nicht.
>Die Frage ist, ob wir �berhaupt starre Hierarchiestufen verwenden.
>Obiges Konzept mit den prim�ren und sekund�ren S�tzen lie�e sich doch
>auch hier anwenden, eine destination kann innerhalb einer anderen
>destination liegen, und diese wiederum in einer dritten.
Die Frage ist ja auch nur, wie das nach aussen geliefert werden sollte.
Intern koennen beliebige Hierachien vorkommen, es geht um das Interface.
In meinem vorgeschlagenen Interface kommt die Rueckgabe in der Struktur NUM,
die eben nur country, area und msn kennt also das was RATE in src[3] bzw
dst[3] erwartet.
>Weiters ist die Frage noch nicht beantwortet, was mit den regionalen
>Ortsnamen passiert.
Doch, das wandert nach destination.c aus, die zone.gdbm sind dann
ausschliesslich Verzonungstabellen.
>Au�erdem w�rde mir auch hier die Hierarchie gefallen (ein Ort liegt in
>einem Bezirk liegt in einem Bundesland usw.)
Wie gesagt, wie schaut das Interface aus - aber auch:
Wozu sollten wir das brauchen koennen?
>bye, Michi
>
leo
_______________________________________________
Rates4linux-devel mailing list
[EMAIL PROTECTED]
http://lists.SourceForge.net/mailman/listinfo/rates4linux-devel
