[AcLab] Vi racconto un fatto

[santec a riseup.net]

>
>
> --- Dom 4/10/09, Shark <the_shark a nitroteam.biz> ha scritto:
>
>> > -la pagina di ogni utente ha un numero di revisione,
>> che cambia ad
>> > ogni aggiornamento: quando l' hai appena creata, la
>> pagina ha il
>> > numero 0000001, al primo aggiornamento diventa
>> 0000002, poi 0000003 e
>> > così via (se, per assurdo, arrivi a 9999999, basta
>> tornare a 0000001)
>>
>> Avevo pensato anche io ad una cosa del genere (un po` piu`
>> informatica
>> ma vabbe`).
>
> In che senso?
> Magari, oltre al numero di revisione, si potrebbe aggiungere un CRC, per
> controllare che nessuno manometta la pagina
>
>
>> Bisogna guardare moolto attentamente questa cosa della
>> cancellazione, o
>> dell'aggiornamento.
>
>
> Sono d' accordo, infatti il sistema corre il rischio di assomigliare un
> po' alle tecnologie usate per il DRM (cioè, io tengo dei dati sul mio
> computer, ed un altro ha la possibilità di cancellarli dando ordini ad un
> MIO programma). D' altra parte, si tratta di dati che non intendo
> conservare, probabilmente (io sto solo offrendo hosting ad un mio amico),
> quindi non dovrei aver interesse a manomettere il sistema. Come ho già
> detto, le copie non sarebbero ospitate su computer scelti a caso, ma solo
> su quelli degli amici (di cui ho deciso di fidarmi, e che comunque possono
> già accedere alla mia pagina, per leggerla, quindi non scoprirebbero
> niente di più, sui miei dati)
>
> Ritengo, invece, che serva a poco spezzettare i dati su più computers:
> dovrebbero essere online tutti per ricostruirli, e ciò non impedirebbe ad
> un malintenzionato di connettersi a tutti per scaricare lo stesso i dati.
>
>
>
>
>
>> Il tutto pero` ha un "difetto". Dobbiamo farlo in modo che
>> alla fine
>> venga fatta una pagina html? Oppure un client che non
>> c'entra con il
>> browser?
>
> Potrebbero funzionare entrambe le soluzioni: dovresti avere comunque un
> programma da installare sul tuo computer, per usarlo come server, quindi
> tale programma potrebbe anche fare da visualizzatore.
>
> Oppure potrebbe trasmettere i dati anche in HTML, così non c' è bisogno di
> curare il rendering grafico, si sfrutta quello esistente del browser (il
> programma sarebbe più semplice da realizzare)
>
>
>>
>> Nel primo caso la cosa si fa complicata (non conosco server
>> html che
>> supportino il p2p, ed e` un'idea secondo me che quelli che
>> ci hanno
>> provato hanno fallito).
>
> Yacy funziona in P2P, ed agisce come server HTML.
>
> Nella mia idea, per leggere la pagina di qualcuno basta inserire il suo
> IP, e per conoscere il suo IP basta collegarsi al server centrale.
> Per permettere l' accesso solo ai tuoi amici, ci sono due soluzioni: la
> pagina potrebbe essere criptata (ed allora ti serve un visualizzatore
> indipendente, che contiene il software di decodifica), oppure per accedere
> ti serve una password, che l' amico ti manda quando ti invita (ed allora
> un browser convenzionale va benissimo).
> Ovviamente, se tu ospiti una copia della pagina di un tuo amico, anche tu
> devi chiedere la stessa password per permettere agli altri di leggerla, ma
> visto che tu sei stato autorizzato a leggerla, conosci già la password.
>
>
>>
>> Nel secondo caso abbiamo piu` liberta` e potrebbe essere
>> fattibile (con
>> molto impegno).
>>
>> Salot
>
>
> Bye



Purtroppo il poco tempo mi impedisce di prendere parte in questo progetto
o anche solo di impiegare del tempo per un'analisi seria. Spero comunque
che le mie osservazioni possano essere utili lo stesso..

* un browser è un programma elaborato. Sarebbe un peccato se gli utenti di
un sistema come quello di cui si sta parlando fossero costretti a
rinunciare, che ne so, alla history, ai preferiti o alle estensioni. Però
in teoria nulla impedirebbe al programma di cui si sta parlando di inviare
una richiesta HTTP, ricevere una risposta (pagina HTML) e aprire il
browser per visualizzarla. A questo punto l'utente potrà cliccare sui link
o compilare dei form se sono presenti sulla pagina, perciò il programma
dovrebbe anche intercettare le richieste HTTP in uscita che partono dal
browser, bloccarle e sostituirle con le "sue" richieste. (vedi ultimo
punto)

* Se questo non fosse possibile o se fosse troppo complicato per motivi
che al momento mi sfuggono, il programma potrebbe almeno utilizzare Gecko
o KHTML come motore di rendering. Questo permetterebbe di utilizzare gli
standard già esistenti (HTML, CSS, JavaScript...) ed eviterebbe di
riscrivere un motore di rendering ex novo.

* A mio parere (ma è un parere molto superficiale, bisognerebbe
verificare!) non dovrebbe essere troppo difficile implementare un web
server. Se non erro non si è ancora discusso su quale linguaggio verrà
usato, ma credo che in tutti i linguaggi più diffusi esistano librerie
adatte allo scopo, con funzioni di livello molto alto (avvia, arresta,
cambia questa opzione...) e quindi semplici da usare.
Mi ricollego al primo punto: invece di intercettare le richieste HTTP in
uscita, il client potrebbe dirigere tali richieste direttamente al server
locale. Le chiamate dirette a un indirizzo particolare (che so:
http://localhost/_out_) verrebbero quindi reindirizzate.

Colgo l'occasione per dire che questo progetto mi sembra utilissimo, che
spero si concretizzi e che spero un giorno di potervi aiutare.

Saluti a tutti
fede