On Sun, May 23, 1999 at 02:04:30PM +0200, Alexander Skwar wrote:
> On Sun, May 23, 1999 at 08:19:09AM +0200, Michael Reinelt wrote:
> > Ich mu� nochmal drauf hinweisen, da� eine solche Zuordnung erstens nur
> > f�r Deutschland gelten kann, zweitens immer wieder gesprengt werden wird
> > (suehe unten), und drittens ich mich mit H�nden und F��en dagegen wehren
> > werde, wenn irgendwann wieder mal was hardkodiertes reinkommen soll, in
> > die Richtung �wenn xy passiert, dann nimm Zone z�. Die Einteilung wird
> > also niemals Funktion haben, sondern dient nur der einfacheren
> > Verwaltung.
>
> Vollkommende Zustimmung.
>
> >
> > Seids euch auch bewu�t, da� die Zonentabelle als Array gespeichert wird
> > (um des einfachen Zugriffs Zone[z] willens), �L�cher� kein Problem sind,
> > aber die Performance und en Speicherbedarf in die H�he treiben. Ich bin
> > nicht willens, hier eine andere Datenstruktur einzuf�hren, ganz im
> > Gegenteil, da irgendwann die explizite Zonennumerierung sowieso fallen
> > wird (vielleicht).
>
> Also sollten m�glichst keine L�cher auftreten, sehe ich das richtig ?
Also gegen die *unz�hligen* "strncmp()" tauchen L�cken in der "rate-xx.dat"
vollkommen unter. Performance-Verluste sind vernachl��igbar.
(Das ist keine Behauptung, sondern ich wei� das! Habe seit 2 Wochen meinen
isdnlog mit Performance-Monitoring am laufen -- einfach mit "-pg" neu
compilieren, also z.b. make clean; make "_CC=gcc -pg", dann eine Weile
laufen lassen, und dann "gprof isdnlog gmon.out" eingeben, und staunen!)
> > > # Zonenzuordnung f�r Deutschland:
> > > # 5 : C-Mobilbox
> > > # 6 : C-Netz
> > > # 7 : D1-Netz
> > > # 8 : D2-Netz
> > > # 9 : E-Plus-Netz
> > > # 10 : Viag City-Partner (E2)
> >
> > und was, wenn die n�chsten Handy-Netze (im 1800MHz-Band oder das neue
> > Super-GSM wie immer es heisst) dazukommen?
>
> Wie Andreas schon vorgeschlagen hat, k�nnte man 11-19 Streichen, bzw.
> nach 200-208 umverfrachten, und h�tte somit von 5-19 Platz f�r Handys.
>
> >
> > > # 11 : Euro City
> > > # 12 : Euro 1
> > > # 13 : Euro 2
> > > # 14 : Welt 1
> > > # 15 : Welt 2
> > > # 16 : Welt 3
> > > # 17 : Welt 4
> > > # 18 : Welt 5
> > > # 19 : Welt 6
> >
> > Wohin gibst du Welt7? Wie kommst du auf Welt1-Welt6? Nur weil eure
> > Telekom sowas anbietet, bekommen die so tolle niedere Zonennummern?
>
> Welt7 w�re 200. Und ja, nur weil die Telekom die Zonen so in etwa
> einteilt, bekommen die so niedere Einteilungen. Da sich aber auch viele
> andere Provider an die Einteilung halten, oder zumindest von der
> Einteilung "inspiriert" zu sein scheinen, halte ich die Einteilung nicht
> f�r so ganz abwegig.
>
> > In �sterreich habe ich von vorneherein auf eine solche Klassifizierung
> > verzichtet, auch weil die Provider teilweise _v�llig_ verschiedene
> > Schemas haben. Und ich denke, wir fahren sehr gut ohne diese Einteilung.
>
> Hmm ? Deine Zonen haben doch aber auch Nummern? Oder mi�verstehe ich
> Dich jetzt ? Wobei aber zu bedenken ist, das es in �sterreich nicht ganz
> so viele Provider gibt, wie hier in Deutschland. Darum finde ich es
> besser, wenn es einen Richtwert gibt, damit man schneller wei�, wo was
> ge�ndert werden mu�.
Michael tippt seine "rate-at.dat" nicht, wie wir, ein, sondern generiert
die mit einem C-Programm!
(Was ist denn aus dem Perl-Script geworden, der alle Tarife reinlutscht?)
Um mal ein "Machtwort" zu sprechen:
Es gibt Bereiche, wo eine Zonen-Nummer mit Sicherheit vollkommen sinnlos
ist: Im Ausland. *Leider* hat sich fast keiner der neuen Provider an die
ziemlich einfache Zoneneinteilung der DTAG gehalten - bestes Beispiel ist
der Provider 3U (momentan im Ausland fast �berall der billigste, und
daher *sehr* wichtig!), der eigentlich f�r jede Auslandsvorwahl einen
eigenen Tarif hat.
Hier halte ich eigentlich eine Notation wie
Z:*
f�r am sinnvollsten, d.h.: lieber isdnlog, denk' dir beim einlesen der
"rate-xx.dat" bittesch�n irgend eine Zonen-Nummer aus, ist mir egal,
welche. Oder andersrum: Lieber isdnlog, jetzt f�ngt eine neue Zone an.
MICHAEL: Hierbei k�nntest Du mit einer simplen Bitmap erst mal die L�cken
ausnutzen, womit das "Performance-Argument" weg w�re!
Andererseits gibt es durchaus Bereiche, wo eine Zonen-Nummer Sinn macht
(*alle* Provider arbeiten mit dieser Begrifflichkeit, warum sollten wir
gerade sagen: Quatsch?)
Und (hier in Deutschland!) gibt es nun einmal wirklich folgende absolut
fixen Zonen:
- Ortszone
- Nahzone / Cityzone
- Regionalzone
- Landesweit
- Handy's
> Nachdem ich jetzt die erste Charge Mails gelesen und beantwortet habe,
> hier ein �berarbeiteter Entwurf zur Zoneneinteilung:
>
> 0 - 9 : Inland
> 10 - 30 : Handies (D-Netze, E-Netze)
> 31 - 39 : Satelitenfunk (Inmarsat, Iridium)
> 40 - 59 : Telefonausk�nfte
> 60 - 79 : Cityruf, Scall etc.
> 80 - 89 : Shared Cost (0180)
> 90 - 99 : Premium Rate (0190)
> 100 - 159 : Internet Tarife
> 160 - 169 : Televotum, etc. (das, was ich erst bei 60.. dachte)
> 170 : Pers�hnliche Rufnummer (0700)
> 171 - 199 : Sonstiges (sollte immer noch ausreichend sein)
> 200 - xxx : Auslandstarife
Komplett akzeptiert!
Und da das sammeln der Tarife *viel* aufwendiger ist, als das programmieren
der sinnvollen Abspeicherung, w�rde ich vorschlagen, genau obige Einteilung
f�r Deutschland einzuf�hren!
Frage 1: Michael, bekommen wir ein "Z:*" ?
Frage 2: Wer r�umt die aktuelle "rate-de.dat" (in unserem CVS) auf ?
>
> Alexander Skwar
> --
> My Site : http://www.digitalprojects.com
> To get my PGP key, send me an email with the Subject: Send PGP Key.
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
