On Tue, Jun 22, 1999 at 11:19:00AM +0200, Leopold Toetsch wrote:
> Hallo
> -----Original Message-----
> From: Michael Reinelt <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
> Date: Dienstag, 22. Juni 1999 06:08
> Subject: Re: zone 1.10
>
>
> >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!!
> >> > - zred.bz2
> >> > - div.tar.bz2
> >Ich bin nicht so gl�cklich mit den .bz2-Dateien, wenn diese eh ASCII
> >sind. Macht das Sinn? Oder wird sonst das CVS elendig langsam?
Es ist fast unglaublich, was der bzip2 da rausholt!
zred.dtag = 1030855 Byte
zred.dtag.bz2 = 245242 Byte
Wir w�rden das "isdn4k-utils" File extrem aufbl�hen, ohne den bzip2 !
> - 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!
> - zred.bz2
> Brauchen wir, um bei Datenformataenderungen neue GDBMs zu erzeugen.Wird vom
> Makefile expandiert, gelesen und wieder komprimiert. Da in den
> Verzonungsfiles (hoffentlich) keine Aenderung notwendig sind, ist bz2 sicher
> das beste Format zum Speichern / Verteilen.
Stimmt.
> >>Der ftp-Spiegel unseres I4L-CVS bei SuSE
> >Aber ich bin �berzeugt, es zahlt sich aus!
> Ack
>
> >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!
> >Wir verwenden die
> >country.dat aber zum Abspalten des L�ndercodes von der Telefonnummer, im
> >obigen Fall �Frankfurt� spalten wir da aber die Ortsvorwahl mit ab.
> >Neben unsch�nen falschen Textmeldungen funktioniert damit die
> >Zonenberechnung nicht mehr.
> >
> >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 Eibtr�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.
> 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
> ...
Dar�ber l��t sich nat�rlich reden. Einverstanden ...
> leo
Ciao,
Andreas
--
Andreas Kool ([EMAIL PROTECTED] * http://www.pweb.de/kool.f)
PGP: 3FBF2411 Fingerprint: B5 35 34 74 25 60 2A 7A 89 06 92 C4 08 BA A5 BD
(To get my PGP key, send me a mail with subject "send pgp key")
Transmission of this message via the Microsoft Network is prohibited
_______________________________________________
Rates4linux-devel mailing list
[EMAIL PROTECTED]
http://lists.SourceForge.net/mailman/listinfo/rates4linux-devel
