linux user group brescia

NOTA: questa mail ho cominciato a scriverla stamattina, quindi tempo sia
un pochino frammentaria, e me ne scuso.

> On Mon, Jun 18, 2001 at 06:08:37PM +0200, Luca Giuzzi wrote:
> > Attenzione...  qui si parla di mirror fra siti non di scaricare le pagine
> >  a casa propria! Per chi vuole editare le pagine, ne esiste una sola 
> >  versione: quella PHP (che e' anche autoritativa)...
> meglio, direi che autoritativo e` il tree del cvs, a prescindere da cio`
> che contiene.
>
> > Statiche per il server, dopo che sono state generate...
> ok
>
> >  Essenzialmente io insisto sul fatto che il sito sia "compilato" e non
> >  "interpretato".
> il problema del compilato vs interpretato, o il solo fatto che qualcuno
> utilizzi il sito in modo dinamico, ed altri no, apre gia` una serie
> di problematiche non indifferente... tipo, ripeto quando avevo gia`

OK, vediamo se ho capito uno dei punti chiave, cosi' almeno se sono
fuori strada mi avvisate subito: Gelmini vuole che eventuali
modifiche apportate al tree cvs siano subito visibili, e la cosa si puo'
fare in vari modi:

1. fare si che il tree cvs si sovrapponga con l'area delle pagine web e
si fa tutto con php (non c'e' bisogno di compilazione, e apache legge
direttamente dall'area cvs).

2. si prepara un "virtual domain" per apache che si comporti come sopra 
[questa e' la soluzione attuale?] e nel contempo si converte i php in
html per l'area web del mirror primario: quindi e' possibile "vedere"
le pagine in tempo reale accedendo con il virtual domain, queste ultime
verranno pero' integrate nel sito solo con una "compilazione" (su richiesta
o in cron).

3. si utilizza un qualunque preprocessore macro (m4?) per le pagine e si
prepara l'html con una "compilazione" controllata via "make".  In questo
modo non e' possibile "vedere" le modifiche fatte se non compilando tutto.
D'altra parte a mio avviso e' piu' economica una compilazione *una tantum*
rispetto ad un accesso web interpretato via php.  L'utilizzo di "make"
permette di evitare ricompilazioni di aree non toccate.

Nel caso 3 nulla vieta di duplicare comunque l'area web standard rispetto
a quella legata al "cvs", che si puo' imporre che sia "up-to-date".

Sempre nel caso 3 la questione e' *come* invocare il make:
- con un cron?
- a richiesta dell'amministratore della macchina?
- legato automaticamente a modifiche nell'area cvs?

Sto capendo giusto? Se si quale di queste e' la situazione attuale?


> detto, volendo aggiungere un miniform di invio automatico di suggerimenti
> (tempo richiesto in php 4 secondi), mi devo preoccupare del fatto che il
> sito stia funzionando nella versione php, e non statica, con tutto quello
> che questo comporta.

Naturalmente si puo' sempre pensare che le parti realmente dinamiche,
quindi legate a form e uso di php, possano risiedere solo su uno dei mirror.

Peraltro, se si pensa alla possibilita' di agganciare dei database o altro,
cose che vengono in mente subito quando si comincia a parlare di form da
compilare, tutto il discorso del mirroring va meditato bene: che si fa del
database?

> la soluzione a mio avviso e`:
> il sito puo` essere compilato, da chi vuol farne un mirror, MA il mirror
> deve essere preso per forza in cvs. ora tu potresti farlo per paolini.

Ma qui bisogna capirsi bene: la form non deve affatto essere scritta in
php.  Piuttosto e' lo script che deve gestirla che dovra' esserlo; ma uno
script puo' fare 1000 cose, e bisogna quindi definire cosa fa prima di
capire se puo' essere mirrorato o no:  se quello che deve fare e' inviare
una modifica al cvs, puo' anche farlo sul mirror ma riferendosi al vero
server "cvs".  Lo script che gestisce una form di solito sta in "cgi-bin",
e quindi si puo' (volendo) gestire in modo diverso i (pochi) script che
risiedono in cgi-bin, rispetto all'insieme delle pagine statiche.

> e` anche vero comunque che il prossimo incontro dovrebbe essere proprio
> sul cvs, sicche` dovremmo riuscire porre fine ad eventuali dubbi e perplessita`.

Bene, qualche data da proporre?

>
> >  e i consigli si mandano in M/L...
> opla`... significa che se il server principale e` giu`, anche i mirror
> funzionano solo in parte. non e` essattamente l'idea che ho di mirror.

Penso che ragioniamo su due livelli diversi: tu pensi ad un "mirror
multifunzionale", mentre io ragiono a livello di semplice "mirror web"
(che puo' avere funzionalita' ridotte nelle parti dinamiche e/o dipendere
per queste dal mirror principale)

> a) un mirror deve NECESSARIAMENTE succhiare i sorgenti del sito dal cvs del lug
> b) una volta succhiati gli aggiornamenti deve essere necessariamente eseguito
>    il Make
> c) le eventuali modifiche apportate al sito devono essere necessariamente
>    apportate sui file php
> d) i link alle pagine statiche (dove per pagine statiche si intende tutte
>    le pagine dove non vi sia interattivita` con l'utente, compilazioni
>    di forma, ecc) devono puntare agli equivalenti html
>
> mi sto sforzando di accontentare tutti, piu` di cosi` non chiedetemi.

Chi c'e' di mezzo, oltre a te, Giuzzi e me? Il Ghido? Cominciamo a formare le
squadre...

Maurizio    [Oh, finalmente un po' di fermento in lista]