Hallo Liste,
> On Mon, Jun 21, 1999 at 05:58:03PM +0200, Leopold Toetsch wrote:
> > int getAreacode(int country, char *num, char **text)
Einverstanden.
> > Beim 1. Aufruf von initZone lese ich das Verzeichnis, in der
> > zone-CC-PPP.gdbm drin ist und lese alle Zonefiles der uebrigen Laender.
> > Diejenigen davon, die eine Areacode-Info haben (und genau eines pro Land
> > sollte das), bleiben geoeffnet.
> >
> > Damit koennen auch reine Areacode-Files fuer beliebige Laender erstellt
> > werden, wo keine Verzonungsinfo vorhanden ist.
> > Wenn wir dann bei 100 Files sind, ist es vielleicht wieder eine Ueberlegung
> > wert, das in eine Datei zusammenzufassen.
Ich bin mir nicht sicher, ob die Verzonungstabelle der richtige Ort f�r
die Ortsbezeichnung ist.
> > int getZone(int provider, char *from, char* to)
Einverstanden.
> > - 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?
> Damit auch gleich zum n�chsten Ergebnis unseres Hacker-Treffens von
> vergangenem Wochenende: Der ftp-Spiegel unseres I4L-CVS bei SuSE
> wird abgestellt. Dieser Bl�dsinn erm�glichte jedem DAU-User, das
> aktuelle CVS auf seinen Rechner zu installieren (ohne solche Infos wie
> oben: "Diese Version kompiliert nicht mal durch ...")
> Ich bin mal gespannt, was morgen bzgl. isdnlog wieder auf der Mailing-Liste
> los ist ....
> Daneben hinderte es *alle* Entwickler, einfach mal zur Abstimmung
> untereinander halbfertigen Code einzuchecken.
> D.h. ich habe mich schon ganz lange nicht mehr getraut, so eine Aktion
> wie heute zu machen, was aber Quatsch ist, da das CVS ja *kein*
> Distributions-Medium ist, sondern eben zur Abstimmung der Entwickler
> gedacht ist.
Ein guter Schritt in die richtige Richtung! Aber: Wir sind uns �ber die
Konsequenzen bewusst:
* in regelm��igen Abst�nden sollte eine _brauchbare_ stabile Version
irgendwo verf�gbar gemacht werden.
* die rate-xx.dat mu� getrennt erh�ltlich sein (funktioniert ja bereits)
* �nderungen an der Struktur in der rate-xx.dat werden erschwert bzw.
m�ssen von der Rate-Crew zweigleisig mitgef�hrt werden (einmal die
offizielle rate.dat ohne Format�nderung, aber mit Tarif�nderungen, und
einmal die �Entwicklerversion� mit dem neuen Format, und nat�rlich
ebenfalls den Tarif�nderungen)
Aber ich bin �berzeugt, es zahlt sich aus!
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�). 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.
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
