Hi alle,
Vorab m�chte ich noch folgendes bemerken: Unser neuer Schl�ssel (TLD)
ist nach aussen hin eigentlich kaum sichtbar. Er wird haupts�chlich vom
Leo verwendet, um zwischen den beiden Bereichen "Telefonnummer <->
Schl�ssel" und "Schl�ssel <-> Name" eine Beziehung herzustellen. Es gibt
da nur eine Ausnahme: rate.dat, da stehen bei den A:-Tags (und bei den
neuen N:-Tags) solche Schl�ssel statt den L�ndernamen. Aber diese neue
rate.dat wird eigentlich auch nicht mehr bearbeitet, sondern entsteht
durch einen (vom Leo zu schreibenden) Preprozessor aus einer
rate.irgendwas, welche so wie jetzt die L�ndernamen enth�lt.
Die Frage ist noch, wie wir die Eingabedateien f�r den Preprozessor
strukturieren. Ene gewisse struktur h�tte ich schon gerne.
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.
In �sterreich wird die rate-at.dat von einem C-Programm erzeugt. Das
m�chte ich eigentlich so beibehalten (oder, Leo?) Sch�n w�re es, wenn
sich der Preprozessor in dieses C-Programm einh�ngen lie�e. 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.
> >Ich denke, wir k�nnen davon ausgehen, da� jede gro�e Stadt einen
> >Flughafen und damit ein solches internationales K�rzel hat.
>
> Flugahafenkuerzel gefaellt mir nicht. Was haltet ihr von Postleitzahl. Ist
> auch ein eindeutiger Schluessel (auch wenn es fuer eine Stadt mehrere gibt
> ist das egal, wir brauchen ja nur einen Schluessel.
>
> Im Prinzip brauchen ja nur die Staedte einen Schluessel, die in der
> rate-CC.dat vorkommen. Das sind eine paar Staedtetarife. Da kann auch die
> Stadtbezeichnung der Schluessel sein, reicht vollkommen.
>
> 2) Vorschlag: Staedteschluessel sind die Staedte selber
* mir gefallen die Flughafenk�rzel, weil sie ja auch ziemlich sprechend
sind (MUC oder VIE)
* es gibt nur relativ wenige St�dte, und die haben einen Flughafen
* Postleitzahl gef�llt mir nicht so gunt, weil sie numerisch ist, und
deshalb wie eine Telefonnummer aussieht
* Der Stadtname gef�llt mir auch nicht, weil wir dann erst wieder das
Problem der unterschiedlichen Rechtschreibung (und der Sprache) haben.
Jochen wollte eine Flughafenliste auftreiben. Wir schauen uns die mal
an, dann reden wir weiter.
> >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.
> >* 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.
> >sonst noch was?
> Eine Funktion die zu einem Land/Stadt eine Vorwahl auswirft.
> isdnrate -CH Rotterdam
> geht jetzt auch schon.
Ok.
> In der Datenbank gibt es primaere Daten (+nnn, oder AT oder Paris) und
> sekundaere Daten (ex. Aliase) die auf einen primaeren Satz verweisen.
> Rueckgabewert ist immer der primaere Datensatz.
> Die Frage ist ob wir zwischen Stadt und Land noch eine Hierarchie 'Gebiet'
> einbauen.
> z.b.
> +1907xxx => (USA, Fairbanks)
> oder
> (USA,Alaska,Fairbanks)
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.
Weiters ist die Frage noch nicht beantwortet, was mit den regionalen
Ortsnamen passiert. Momentan sind sie ja in der Verzonungstabelle
mitgespeichert (was mir �berhaupt nicht gef�llt! Ich erinnere an das
Beispiel des providers, der �berhaupt keine Verzonung hat, und man
trotzdem eine Dummy-Verzonung angeben mu�, um an die Ortsnamen zu
kommen.).
Au�erdem w�rde mir auch hier die Hierarchie gefallen (ein Ort liegt in
einem Bezirk liegt in einem Bundesland usw.)
bye, Michi
--
netWorks Vox: +43 316 692396
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
