Hi Leo, Hallo Leute,
Irgendwie bewegt sich in dieser Sache nichts. Deshalb reite ich nochmal
drauf herum:
> >Grunds�tzlich: W�rst du einverstanden, die Aufgabe von country.c bzw.
> >den Inhalt der country.dat in deine neue destination.gdbm zu �bernehmen?
> Andere Loesung, s. auch mein gestriges Posting bez. coountry-de.dat. Diese
> ganzen Aliasse und ungenauen Schreibweisen sind in einem Hash ausserst
> unbequem. Daher mein Vorschlag: Aliase raus aus rate-CC.dat, ungenaue
> Schreibweisen raus aus rate-CC.dat.
> Eindeutige Namen (N:) sind der Freund einer Hash-Datenbank.
> Ich sehe darin kein Problem. Die Aliase werden in country-de.dat verwaltet.
> Beim Anlegen/Pflegen eines Providers laueft mein Perl-Hack ueber die
> rate-CC.dat und ersetzt Aliase usw. durch die exakte Schreibweise des
> :Tags - wir haben einen eindeutigen Key.
Jein.
Ich will cut&paste aus der Homepage eines providers in die rate-xy.dat.
Damit brauchen wir verschiedene Schreibweisen. Wenn eine Art
Pr�prozessor dr�berlaufen mu�, dann k�nnen wir gleich alle Namen durch
Nummern ersetzen. Also entweder oder - so eine Zwischenl�sung gef�llt
mir �berhaupt nicht.
Aber: Die Geschichte mit USA, Kanada, +1 usw. w�rde auch die Variante
mit �nur Nummern� �berlasten, weil da einfach so viel Datenmaterial
zusammenkommt, da� rate.c in seiner jetzigen Form damit nicht zurande
kommen wird (oder langsam wird und/oder sehr viel Speicher verbraucht).
Eine andere Frage bzw. Idee: Gibt es irgendeinen klaren kurzen
internationalen L�nderschl�ssel? Dann k�nnten wir die destination.dat ja
in zwei Bereiche aufteilen:
a) Zuordnung Vorwahl - Landesschl�ssel
b) Landesschl�ssel - Landesname (ev. mit Aliases)
a) w�re international, nur b) m�sste f�r jede Sprache �bersetzt werden.
Dieser Landesschl�ssel k�nnte dann auch alternativ beim A:-Tag stehen,
damit w�ren F�lle wie "USA" und "Kanada" sehr sauber dargestellt.
Das mit Leo�s R-Destination verstehe ich noch nicht ganz, aber wenn�s
Sinn macht, Leo hat da sicher viel Hirnschmalz investiert.
Was ich einfach gerne h�tte: eine zentrale Stelle, wo L�ndernamen und
Aliase und Vorwahlen verwaltet werden. Die jetzige Form der country.dat
st��t an ihre Grenzen (bez�glich Rechenleistung, Speicherplatz,
Wartbarkeit, Funktionalit�t). Ich will nicht, da� wir country.c
erweitern, ich will sie ersetzen. Leo�s Know-How mit dbm-Dateien
sollen/m�ssen wir hier n�tzen.
Lie�e sich meine Idee mit dem Landesschl�ssel nach oben hin
(Gebietsschl�ssel) und nach unten (Bundesl�nder, St�dte) erweitern? Ich
meine, sprachunabh�ngig?
Solche Landesschl�ssel k�nnten ja auch recht kurz sein, internationale
Autokennzeichen w�ren ein Ansatzpunkt, oder diese Flughafen-K�rzel (MUC
f�r M�nchen, oder VIE - Wien).
Ich m�chte auch gerne auf jeden Fall den Landesnamen und die Aliase in
einer Datei. So ist es leichter zu pflegen, leichtrer zu �bersetzen, und
vor allem: Wer bestimmt, da� ein name der �richtige� Name ist, und ein
anderer der Alias?
Leo: K�nnen dbm &Co nur Hash, oder kannst du auch sequentiell speichern?
Wie schnell geht das? k�nntest du mal eine Testlauf machen, ein e Datei
mit 340 Landesnamen (so viele haben wir momentan in der country-de.dat)
erzeugen, und sequentiell durchsteppen, und ein paarmal wld() dazu
aufrufen?
zum Thema Preprozessorlauf: wenn schon, dann ersetzt der preprozessor
alle Landesbezeichnungen durch diesen Landesschl�ssel. Damit haben wir
sehr kurze Startzeiten vom initRate() (kein L�ndernamen-Matching mehr).
comments?
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
