> > >Ich bin mir nicht sicher, ob die Verzonungstabelle der richtige Ort f�r
> > >die Ortsbezeichnung ist.
> >
> > Die Vorwahlnummern sind schon als Schluessel drin. Der zusaetzliche Text ist
> > sehr leicht und effizient zu handhaben. Das Areacode-Handling ist jetzt ca.
> > 10% des vorhergehenden.
> > areacode.c 23694 byte
> > zone.c 16930 byte
> > (Jaja + gdbm)
>
> Die Idee, die Ortsbezeichnungen dort auch noch mit einzutragen, finde ich
> echt Klasse! das bleibt genau so!!
Naja, ich misch mich da eh nicht ein. Mir gef�llt nur die Randbedingung
nicht, da� der Text bei genau einer der Verzonungstabellen dabei ist,
bei den anderen nicht.
> Wir w�rden das "isdn4k-utils" File extrem aufbl�hen, ohne den bzip2 !
Gut, �berzeugt.
> > - div.tar.bz2
> > Das sind interne Dateien, die die Ausgangsdateien fuer die Erstellung der
> > Zonefiles enthalten. Ich habe schon einmal zur Diskussion gestellt ob wir
> > die ueberhaupt im CVS halten sollten, oder nur intern.
>
> Entsprechend der guten alten Freeware policy sollten wir auf jeden Fall
> alle Files publizieren, die n�tig sind, um alles jederzeit neu zu erzeugen!
Ja, auf jeden Fall!
> > >Noch ein Problem gibt�s, das ich dem Andreas schon kurz erz�hlt habe: In
> > >der Country-de.dat stehen neben reinen L�ndern auch Nummern innerhalb
> > >der L�nder (z.B. �GB Mobilfunk�, oder �Frankfurt�).
> >
> > Da drin sind auch etliche Staedte. Die gehoeren raus.
>
> Nein. Bei diversen Providern kosten St�dte weniger, als das Land drumrum.
> (Das nennen viele "Eurocity-Tarif") Daher stehen die da drin!
Richtig. Ich mu� euch (ausser Andreas) daran erinnern, wozu die
country.dat �berhaupt implementiert wurde: Um das A:-Tag mit Namen statt
Vorwahlen zu f�ttern.
> > >Mein Vorschlag zur Abhilfe: Es gibt in der country.dat ein Tag �C:�,
> > >unter dem nur echte L�nder gespeichert werden, und ein zus�tzliches Tag,
> > >dessen Namen ich noch nicht weiss, unter dem alle anderen Eintr�ge
> > >verwaltet werden. �ber einen zus�tzlichen Parameter im
> > >getCopuntry()-Aufruf kann gesteuert werden, ob man diese zus�tzlichen
> > >Eintr�ge mitdurchsuchen will oder nicht. Bei der Umwandlung von
> > >L�ndernamen in Vorwahlen (rate-xx.dat) sollen diese Eintr�ge verwendet
> > >werden, beim Abspalten der Landesnummer nicht.
>
> Unn�tig. isdnlog "wei�", in welchem Land er gerade l�uft, und kann
> entsprechend reagieren.
Mir geht�s nicht nur um das Inland, sondern auch ums Ausland. Ich habe
eingesehen, da� da die Verzonung nicht notwendig ist, aber die
Ermittlung des Ortsnamens zur Vorwahl ist schon praktisch. Areacode hat
das gekonnt. Au�erdem will ich intern saubere Daten haben, d.h. im Feld
�country� soll nur die landesvorwahl stehen, im Feld �areacode� wirklich
die Ortsvorwahl etc. Ich bitte, �ber meinen obigen Vorschlag nochmal
nachzudenken.
> > Warum nicht eine klare Trennung der Funktion:
> > country.dat ... enthaelt die Laendervorwahlen / Namen und dient
> > ausschliesslich zum Abspalten der Landesvorwahl.
> >
> > Der Rest kommt in eine nummern-div.gdbm und dient zum Nachschlagen des
> > Namens:
> > 43699 Oester. Mobilfunk
> > 43676 Oester. Mobilfunk
> > ...
> > 41800 Freephone Schweiz
> > 4179 Schweiz Mobilfunk
> > ...
Das w�re grunds�tzlich auch m�glich. Ich w�rde das allerdings lieber in
einer Datei, n�mlich der country-de.dat, belassen. Wie gesagt, der
prim�re Zweck ist nicht mal das Abspalten des Landescodes, sondern das
Parsen von A:-Tags.
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
