linux user group brescia

On Tue, Jun 19, 2001 at 04:32:44PM +0200, Maurizio Paolini wrote:
> 
[...]
> > >  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).
> 
Una nota: il tree cvs non e' immagazzinato in modo "nativo"... i files,
 per essere editati, devono essere copiati dal cvs... l'opzione 1
 richiede comunque una operazione di checkout.

apache "sopra" cvs (senza compilazione, senza niente) francamente mi fa
 molta paura. [nota: non mi fa paura perche' non mi fido di chi gestisce 
 il tutto... mi fa paura perche' le vulnerabilita' potenziali di cvs si
 moltiplicano per quelle di php che si moltiplicano per quelle di apache...
 non bene!]

> 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).
> 
visto che un checkout si deve fare comunque, tanto vale che il checkout 
 sia seguito da un make, no?

> 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.
> 
Yep... questo e' quello che preferirei anche io...
 volendo si puo' automatizzare il checkout/compilazione approfittando della
 mailing list cvs a lugbs.linux.it.

> 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?
> 
Per il punto 3: una soluzione e' inviando mails "particolari" ad un indirizzo
 prefissato... semplice e pulita :))

> 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?
> 
Esatto... mi piace l'idea di "copia autoritativa sul cvs" poiche' questo
 limita i rischi di modifiche indipendenti...
 d'altro canto alcuni servizi non sono (e non devono) essere replicabili
 [e.g. le immagini dei CD]; se si pensa ad un backend con un database server
 [possibile a regime], allora si deve tener conto che in caso di downtime
 del database quei dati sono irraggiungibili... sia che le form in php
 siano sul master che sul mirror. Mirrorare i database via cvs non e' una
 buona idea .... :)

Ciao,
 lg