[Gfoss] presentazione e nota su una email ricevuta dal PCN

[Cristoforo Abbattista]

> Non si passa mai da digitale ad analogico e viceversa, quindi Shannon
> resta tranquillo.
>   
Non era chiaro dal discorso dei dpi e infatti ho ipotizzato ti riferissi 
all'analogico. La questione quindi mi resta oscura. Per me i pixel e la 
risoluzione relativa sono le informazioni necessarie.
>> Nel caso specifico i numeri reali che ho riportato e che voi potreste
>> sperimentare, dimostrano che la mappa viene prodotta in 10 secondi e poi
>> io l'ho portata a casa in 1 secondo.
>>     
> Mi interesserebbe sapere come hai fatto a stabilire che l'immagine
> viene prodotta in 10 secondi, visto che
> l'unica misurazione di cui puoi disporre e' il tempo con cui ti arriva a casa.
>
> Sei forse partito dal presupposto che a te arriva a casa senz'altro in
> 1 secondo ?
>
> E quindi il ritardo e' imputabile per forza ai servers ?
>   
Conosco i miei polli, e in questo caso il pollo è ArcIMS. Nessuna 
ipotesi quindi. L'interazione con ArcIMS si basa sull'utilizzo di ArcXML 
che funziona così:

<client>Caro Server di mappe mi fai la mappa così?</client>
    x secondi dopo, utilizzati per produrre la mappa, il server risponde
<server di mappa>la puoi trovare a questo indirzzo http</server di mappa>

<client>caro server web mi dai questo file?</client>
<server web>tieni</server web>
    y secondi dopo la vedo sullo schermo

mediamente x=10 e y=1 (e suppongo pure con pochissimi utenti connessi; 
forse solo io)
>   
>> Abbastanza in disaccordo. Se progetto un servizio è perchè penso che
>> mediamente il pubblico possa usufruirne, e lo possa fare anche in
>> maniera gradevole. Di questo pubblico io  posso solo ipotizzare il
>> dimensionamento tecnologico per ciò che riguarda l'HW, il SW, la rete.
>> Io utente oggi non posso vedere un film a colori se ho la TV in bianco
>> in nero. Forse nemmeno nelle partite di calcio fanno più in modo che una
>> squadra abbia la casacca molto chiara e l'altra molto scura. Insomma
>> alcune assunzioni le dobbiamo fare.
>> L'alternativa sarebbe non fornire informazione, e chiaramente zero byte
>> vengono trasferiti molto velocemente su tutte le reti.
>>     
>
> Il paragone non regge.
>   

> Per la televisione serviva un apparato trasmittente abbastanza potente
> e capace per la trasmissione bianco/nero o a colori che sia.
> La Televisione inviava e chiunque fosse con la televisione accesa vedeva.
> Per la lettura di pagine via web, il paradigma si basa non sull'invio
> , ma sulla richiesta.
> Ovvero e' l'utente da casa che invia una request e scarica la mappa.
>
> Per la televisione la banda e' uguale per tutti gli utenti. Puo'
> cambiare la sensibilita' la le immagini si muovono sempre alla solita
> velocita' per tutti, se gli impianti di ricezione sono migliori le
> immagini sono piu' nitide, ma la velocita' di movimento delle immagini
> e' la stessa per tutti.
>
> Nel caso della ricezione via web.
> La nitidezza (intesa come qualita' del dato) e' un parametro che e'
> uguale per tutti.
> Quello che cambia e' la velocita con cui le scarichi e quindi in
> definitiva il movimento (inteso come numero di immagini scaricabili al
> secondo).
>
> Quindi e' proprio l'opposto della televisione.
>   
In realtà il paragone non doveva essere preso alla lettera, volevo solo 
porre l'attenzione sul fatto che l'ingegnere fa quel che po', 
ipotizzando al meglio le situazioni che non può governare. Nel 19xx 
hanno preso il rischio, e accettato il costo, di inviare un po' di 
energia anche sul pezzo di banda destinato al colore, anche quando di TV 
a colori ce ne erano ben poche in giro. Un po' come il ministero che 
vuole fare un server potentissimo che fa delle amppone anche se non 
tutti ne godranno appieno.
Non puoi affermare quindi che è inutle fare server prestanti perchè 
tanto io vado a 56 kbps. Che poi non è nemmeno vero a prescindere.
Se hai 56 kbps o ti accontenti di meno informazione (TV in BN e piccole 
mappe in poco tempo) o di aspettare più tempo (TV a colori e grandi 
mappe in molto tempo)

ciao
    Cristoforo
> Ciao,
>
>   


-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://www.faunalia.com/pipermail/gfoss/attachments/20081015/f8331b80/attachment.htm>