linux user group brescia

On Mon, Jun 18, 2001 at 05:38:01PM +0200, andrea gelmini wrote:
> 
> On Mon, Jun 18, 2001 at 03:20:23PM +0200, Luca Giuzzi wrote:
> > No... in quanto cvs sarebbe per i sorgenti (tutti in php/perl/python/ruby
> >  o quello che vuoi) mentre wget per i files compilati in html...
> > A [tramite make]
> non concordo totalmente. la necessita` della soluzione mista statica/dinamica
> e` un ibrido, che poco mi piace, per accontentare le richieste dei rompiballe
> (leggasi: paolini e giuzzi).
> siccome voglio assicurarmi un posto nell'alto dei cieli ho accontentato tutti
> e due... ma il risultato non mi esalta molto.
> 
CHEAP!!
Get some real estate in hell: be warm for all of eternity!
(scusate, non potevo resistere)

> > Vero... verissimo, direi... il problema e' che qui non si sta parlando tanto
> >  di "risparmiare la banda" quanto di "fare nel modo piu' semplice possibile".
> ehm... risparmiare la banda e` a mio avviso importate, visto che tutti non
> sono borghesi, e possono permettersi di scoreggiare su T1, ecc...
> non mi parlate di rendere il tutto piu` semplice possibile, con le manovre
> per avere link relativi/assoluti, pagine statiche/dinamiche, ecc
> 
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)...

> > a) le pagine statiche siano EFFETTIVAMENTE statiche;
> > b) le pagine dinamiche siano facili da identificare;
> > c) il meccanismo di replicazione funzioni nel modo piu' semplice possibile
> >    e non richieda una logica di "post-processo" sul server mirror.
> a) non si puo` fare... ovvero, se non vogliamo sclerare ogni volta che
> dobbiamo aggiungere una voce nel menu, dobbiamo accettare il fatto che
> tutte le pagine siano dinamiche.

Statiche per il server, dopo che sono state generate...

> b) in che senso? in realta` di dinamico c'e' veramente poco, ma nel momento
> in cui si iniziera` a mirrorare, ed a utilizzare il sito in modo statico,
> tutti i nostri vantaggi andranno a balle... del tipo "ho modificato la
> tal pagina dei log_eventi"... che se lo fai sul file txt, dal quale poi
> viene generata la pagina, siamo tutti felici e non ci sono problemi, altrimenti
> alla fine, so gia` che mi tocchera` prendere pagine statiche modificate
> per renderle dinamiche (alla faccia di cvs e php).
Appunto... perche' usare php allora?
La risposta naturale e':
 "perche' in questo modo il sito e' piu' semplice da gestire"
 e su questo concordo appieno. Il punto e' che le pagine cosi' ottenute non
 devono essere rigenerate ogni volta che un utente si collega... basta
 rigenerarle (dai sorgenti) ogni volta che si cambia il file txt.
 Essenzialmente io insisto sul fatto che il sito sia "compilato" e non
 "interpretato".
> c) il meccanismo gia` c'e`... si chiama cvs update in cron, e non avrebbe
> presentato nessun problema
> 
Mah... non completamente d'accordo, ma si puo' anche fare... modulo 
la ricompilazione
> > D'altro canto, per omogeneita', etc. etc. e' anche il caso che
> > 1) le pagine siano scritte tutte allo stesso modo sfruttando funzionalita'
> >    di macro per semplificare lo sviluppo;
> > 2) esista un repository pubblico cui si possano inviare le modifiche e che
> >    tenga traccia della storia del sito;
> > 3) le modifiche alle pagine non siano automaticamente trasferite sul sito;
> > 4) sia possibile incorporare con poca fatica pagine REALMENTE dinamiche quando
> >    e se ci saranno.
> ad esempio, la soluzione mista ci fotte gia` incredibilmente... faccio un
> esempio banale... ora per poter utilizzare il sito in entrambi i modi, ho
> dovuto far puntare i link, all'interno delle pagine, all'equivalente in
> html, piuttosto che in php...
 argh... ma di questo si puo' tenere conto in fase di compilazione con un
 sed -e "s/\.php\/.html/g"
 (no... cosi' non va bene... ma qc del genere si')
> detto questo, se volessi anche mettere solo uno
> spazietto dove dire "scrivi qui un suggerimento per il lug fai invio e parte",
> a questo punto devo preoccuparmi del fatto che si stia puntando ad una pagina
> in php oppure in html...
> 
Perche'? ... il post dovrebbe andare comunque su di un link assoluto...
 e i consigli si mandano in M/L...
> > La risposta a questi due ordini di istanze e' il doppio sistema wget/cvs:
> >  cvs per l'upload delle pagine, seguito da un make per la generazione dei
> >  contenuti statici;
> >  wget per il mirroring della componente statica del sito.
> personalmente mi sta sulle balle se qualcuno mi mirrora il sito con il wget
> piuttosto che con il cvs.
>
cvs non mirrora il sito... mirrora i SORGENTI del sito...

> > La necessita' di risparmiare banda fra server principale e mirror e' (al
> >  momento) secondaria, sebbene non sia mai male.
> sara` anche secondaria, ma visto che e` tutto pronto, non capisco cosa
> aspettare per usarla.
> 
ti riferisci a cvs o wget?

> > Perche' il sistema wget funzioni cosi' come e' adesso, e' opportuno che le
> >  pagine interne al sito e statiche si referenzino a vicenda con links relativi;
> >  i riferimenti a pagine esterne O DINAMICHE dovrebbero essere assoluti.
> gia` e`. al momento l'esigenza per le dinamiche non si presenta, forse poi.
> 
> >  [questa nota non e' di policy... e' solamente una considerazione pratica
> >  per l'infrastruttura attuale... ]
> yeppa.
> 
> > Nota a margine: fra i vantaggi nella generazione di pagine statiche (ove
> >  possibile) c'e' quello di poterle processare con htmltidy e validare col
> >  w3c... per un lug questo non fa certo male!
> non cominciamo a mettere immaginette del cazzo in giro...

le immagini sono benvenute se corredate di tag ALT="..."
> 
> by the way, sto mettendo ora online il nuovo sito (anche perche` e` inutile
> che continui a controllare i link... finche` non sono online gli scazzi
> non saltano fuori)...
> ho fatto la faq, e sistemato un po' di cose nei contenuti... comunque se
> guardate i log di cvs trovate tutto.
> 
Perfettamente d'accordo su questo...

ciao,
 lg
> ciao,
> andrea

--