ImcItalyIndymediaMir

Table of content :

Mir

Mir (in Russo "Pace") è un CMS scritto in Java da Zapata e Indy.de

La sua particolarità consiste nell'essere un CMS che non produce pagine "On the fly" ma pagine statiche che possono essere separate su diversi server.

Alcune considerazioni sull'utilizzo di Mir di Indy Italia

Indy Italia ha deciso di utilizzare Mir come puro aggregatore di contenuti dei nodi locali in una logica di assoluto rispetto delle autonomie dei nodi. L'aggregatore non può scavalcare in alcun modo le decisioni assunte dal nodo locale e non possiede alcuna "redazione".

Al nodo locale spetta anche il compito di decidere se un post vada nascosto o meno e l'aggregatore non può incidere sulle scelte del nodo locale.

Questo comportamento dell'aggregatore, che abbiamo sintetizzato nel concetto "tutto il potere ai nodi locali", è automatico e non richiede operazioni di admin , salvo alcuni casi che andiamo ad elencare:

Le attività consentite agli admin dell'aggregatore sono le seguenti:

• Gestione dell'inserimento/cancellazione delle top feature nel seguente modo:

a) La feature introduttiva, qualora non pervenga tramite feed, una volta consensuata dalla lista deve essere introdotta manualmente nel sistema da un amministratore.

b) La feature introduttiva, se eletta consensualmente tra quelle esistenti pervenute tramite feed, deve essere "taggata" come top feature da un amministratore.

• L'accorpamento dei post multipli collegando al primo post pervenuto i rimanenti

• L'introduzione / rimozione di sezioni sulla base di richieste consensuate dalla lista

• L'aggregazione / disaggregazione di nodi locali o affiliati che avviene con il consenso della lista

• La normale gestione utenti e/o le usuali operazioni di manutenzione

Architettura di Mir

Un interessante documento sull'architettura di Mir lo trovate qui http://threespeed.org/~pietro/mir-developers-guide-0.0.1/developers-guide.html

L'aspetto centrale di questa architettura è che c'è un sito di "produzione" e uno di "pubblicazione" e che i siti possono stare su server differenti.

Questo perchè il Mir che gli utenti navigano è una collezione di file statici; le pagine non sono prodotte all'istante mediante una interazione con qualche database (come accade ad esempio per i CMS in PHP) ma vengono prodotte dal server di produzione e depositate in quello di pubblicazione ad intervalli regolari sotto l'effetto di un cron.

Il fatto che il sito prodotto da Mir sia un insieme di file statici ne favorisce inoltre il mirroring su altri server che possono essere sincronizzati col Mir originale mediante rsync.

il "cuore" di Mir: il file producers.xml

Il file producers.xml è il file nel quale vengono specificati i comportamenti dei Job. Se infatti per trasformazioni radicali sarebbe necessario agire direttamente sulle classi di Mir mediante una ricompliazione del codice modificato, possiamo comunque ottenere buoni risultati attraverso la semplice manipolazione di questo file.

Per le note base si veda il riferimento architettura Mir

Si prenda ad esempio il producers.xml di Italy Indymedia. Per ovviare al problema dei post "multipli" essi sono stati accorpati con una semplice procedura (vedi paragrafo). Il comportamento del "sample" degli articoli però deve essere modificato forzandolo a ricostruire gli ultimi 50 articoli anzichè gli ultimi 10.

Nel producers.xml quindi, modificando il valore della key _limit_ da 10 a 50 si ridefinirà il limite nel ciclo Enumerate sottotante consntendo al sistema di produrre gli ultimi 50 articoli presenti nel database.

In seguito a questa modifca, il comando ant e un rilancio di Tomcat renderà attivi i cambiamenti.

Allo stesso modo si interviene per implementaree il comportamento dell'ggregatore riguardo alla possibilità dei nodi locali di hiddare i propri post. Nel producers.xml, nel nodedefinition Pull, si introduce un controllo che verificata la natura del feed come hidden modifica il suo flag di visibilità sul database, togliendolo di fatto dalla pubblicazione nell'aggregatore.

Anche in questo caso non è stata scritta nemmeno una riga di codice in Java

Interfaccia gestione di Mir

Login

Pannello di controllo

Il pannello di controllo di Mir è suddiviso in sezioni che consentono di gestire i contenuti (articoli, media, commenti ecc...), effettuare ricerche, lanciae i job.

Generazione Manuale (job)

I job sono dei processi che hanno il compito di "produrre", raccogliere ed organizzare le informazioni che verranno visualizzate sul sito. Questo avviene attraverso la raccolta delle informazioni nel producer , informazioni che vengono quindi passate al relativo template che genera la pagina finale (HTML).

L'interfaccia presenta sulla sinistra la lista dei producer disponibili. In realtà la pagina che vedete nella generazione manuale è niente più che la viusalizzazione dei producers nel file producers.xml, sotto la directory etc/producers di mir.

La "generazione manuale" qui sta ad indicare che questi job possono esser lanciati manualmente. Di norma, i job verranno lanciati da un processo cron che manda in esecuzione, nell'ordine desiderato, quelli necessari all'aggiornamento del sito.

Ogni job possiede diversi "verb", cioè modalità con cui il processo viene lanciato, una sorta di specializzazione del job.

A sinistra c'è quindi l'elenco dei job disponibili mentre a destra verrà evidenziato il job (o i job) che è in lista per essere eseguito, che è in esecuzione o che è appena stato processato.

Per ogni job viene indicato lo stato, cioè se esso è "processed" (processato), "processing" (in esecuzione), "pending" (in attesa). I job porcessati avranno anche l'indicazione del tempo espresso in secondi loro dedicato. I job inoltre possono essere eliminati dalla coda dei processi.

Segue l'elenco dei job di Indy Italia

Articles

Produce gli articoli che verranno visualizzati nel sito. Possiede tre "verb".

• changed indica la produzione degli articoli che sono stati modificati

• all indica la produzione di tutti gli articoli

• sample indica la produzione di un numero limitato di articoli (es. gli ultimi 30, 100, 200)

Navigation

Genera la colonna sinistra

Static Images

Startpage

Genera la pagina home, con le features e gli articoli nel newswire quadripartito

Media

Genera i media

Getloalfeatures

Genera le features prese dai nodi locali

Getlocalcomunicati

Genera i comunicati presi dai nodi locali

Getlocalrassegne

Genera le rassegne stampa prese dai nodi locali

Getlocalcommenti

Genera i commenti presi dai nodi locali

Getlocalnotizie

Genera le notizie prese dai nodi locali

Getlocalhidden

Genera gli hidden presi dai nodi locali

Staticpages

Genera le pagine statiche (mission.shtml, moderation.shtml ecc...)

Add/Edit article

Utilizzato per aggiungere un articolo o editare un articolo esistente. Introducendo il numero di ID dell'articolo da editare nel campo "open article" si apre l'articolo esistente in editing. Questa operazione risulta comoda nella gestione dell'accorpamento degli articoli doppi [vedi paragrafo]

Media

Articles / tipologie di articoli

Sotto la sezione Articles vengono evidenziate tutte le categorie di articoli presenti nel CMS. Accanto a quelle di default verranno riportate tutte le categorie definite dall'utente, come ad esempio quelle riservate ad accogliere l'elenco degli indirizzi dove "pescare" i feed prodotti dai nodi locali.

Funzioni di Super Utente

Nella sezione dedicata alle funzioni Super_utente c'è la possibilità di inserire i nuovi "topics", gestire gli utenti, imporre alcune regole di accesso (ad esempio tramite le misure anti-abuse è possibile inibire il posting degli utenti o subordinarlo ad una password) ecc... Altra funzionalità importante è quella dell'article type.

Gestione aggregatore

Linee guida dell'aggregatore

A seguito del processo di localizzazione intrapreso da Indymedia Italia è sorta la necessità di raccogliere in un unico sito i contenuti prodotti dai nodi locali, organizzandoli all'interno di un aggregatore nazionale. Al fine di non sovrapporre al network così riconfigurato un aggregatore come nodo a sua volta produttore di contenuti si è deciso di inibirne la possibilità di pubblicazione diretta. Per pubblicare un articolo che compare sull'agrgegatore l'utente deve passare obbligatoriamente da un nodo locale di indymedia oppure da uno dei siti "affiliati" e aggregati assieme ai nodi locali.

L'aggregatore ha un ruolo e dei compiti ben definiti, all'interno di una filosofia di utilizzo che abbiamo ricordato all'inizio di questo documento. E' importante sottolineare quindi che l'aggregatore non pratica nessuna selezione dei post, non può cancellare, nascondere ne editare i post pervenuti se il nodo locale interessato non lo consente. Gli admin che agiscono sull'aggregatore non hanno facoltà di interferire sul lavoro e le scelte praticate dai nodi locali ed agiscono solo nell'ambito dei punti già elencati che ricordiamo qui per ulteriore chiarezza:

• Gestione dell'inserimento/cancellazione delle top feature nel seguente modo:

a) La feature introduttiva, qualora non pervenga tramite feed, una volta consensuata dalla lista deve essere introdotta manualmente nel sistema da un amministratore.

b) La feature introduttiva, se eletta consensualmente tra quelle esistenti pervenute tramite feed, deve essere "taggata" come top feature da un amministratore.

• L'accorpamento dei post multipli collegando al primo post pervenuto i rimanenti

• L'introduzione / rimozione di sezioni sulla base di richieste consensuate dalla lista

• L'aggregazione / disaggregazione di nodi locali o affiliati che avviene con il consenso della lista

• La normale gestione utenti e/o le usuali operazioni di manutenzione

Per essere aggregati

Mentre prosegue in lista il dibattito sulla definizione dei criteri per essere inclusi nell'aggregatore, diamo un'occhiata a quello che dal punto di vista tecnico dovrà essere prodotto dal nodo locale per poter essere aggregato con successo.

Per ogni tipologia di feed deve essere specificato l'URL relativo e comunicato agli admin dell'aggregatore. Con l'organizzazione attuale delle informazioni il nodo locale deve quindi fornire gli URL contenenti i feed per:

• features INTERNAZIONALI
• features NAZIONALI
• features LOCALI
• newswire (notizie)
• newswire (commenti/analisi)
• newswire (rassegne stampa / repost)
• newswire (comunicati)
• newswire (messaggi hiddati)

Questi ultimi feed sono particolarmente importanti perchè l'aggregatore non può "nascondere" un post se il nodo locale non lo inserisce esplicitamente tra i post hiddati fornendo allo stesso tempo il feed prodotto e aggiornato. In caso contrario sull'aggregatore rimarranno i riferimenti (titoli e descrizioni) ai post che scompaiono dai nodi locali.

Per un corretto funzionamento dei feed dei messaggi hiddati, il nodo locale dovrà produrre il feed in modo che i nodi link e guid abbiano lo stesso identico valore

Es. ... <link>http://xxxx.indymedia.org/article/1535</link> <guid>http://xxxx.indymedia.org/article/1535</guid> ...

Come faccio a:

Aggiornare la feature principale

Questa feature, che è la feature che compare in testa all'aggregatore e che ha un comportamento differente rispetto a quelle aggregate nelle tre colonne sottostanti, può arrivare da un nodo locale sotto forma di feed, e finire quindi tra le feature presenti nel database, o essere introdotta come feature direttamente dall'aggregatore sulla base di un testo consensuato dalla lista. Il procedimento è identico a quello che si farebbe per inserire un qualsiasi altro articolo: dal pannello di admin si clicca sul link "new article" e si inseriscono i dati dell'articolo, settando l'article type a [Super Feature] oppure editando l'articolo esistente inserendo nel campo Address la stringa 'TOP'. L'articolo marcato come 'TOP' o quello che appartiene alla categoria [Super Feature] con data più prossima viene valutato come feature speciale e verrà posizionato nella pagina principale dell'aggregatore in alto, con l'immagine alla sua sinistra.

Poichè l'immagine dovrebbe essere larga 300px, la forma dell'immagine e la lunghezza del testo alla sua destra potrebbe creare un "buco" sotto l'immagine. Per ovviare a questo inconveniente anti estetico se il campo "Phone" della [Super Feature] viene riempito con "LAST" allora l'aggregatore visualizzerà sotto la foto una tabella con gli articoli più recenti arrivati sull'aggregatore, inclusi ovviamente i commenti, le analisi e le rassegne stampa, per ripristinare un minimo di simmetria sulla pagina.

Aggiungere una nuova tipologia di articolo (es. features, newswire, comunicati ecc...)

Nella sezione Funzioni Super Utente c'è la possibilità di definire nuovi article type. Ogni volta che abbiamo la necessità di creare una nuova "famiglia" di articoli quindi possiamo definire la nostra tipologia di articoli in modo che poi diventi una scelta "possibile" per l'open posting (qualora attivato) o per le funzioni di aggregazione dei feed.

Ad esempio, l'aggregatore deve consentire la gestione dei post hidden senza intervento diretto di un admin, delegando il compito al nodo locale. Il problema infatti di un post che prima di essere hiddato sul nodo locale finisce sull'aggregatore è un problema reale. Definiamo quindi un nuovo article type che chiamiamo localhiddenfeed e uno che chiamiamo localhidden.

Il primo conterrà essenzialmente l'url nel quale pescare i feed relativi ai post hiddati e conterrà quindi n url, uno per nodo locale.

La raccolta di questi post verrà inserita nel database assieme a tutti gli altri articoli e verrà contrassegnata da Mir come appartenente alla famiglia localhidden.

Questa informazione verrà quindi utilizzata dal producer per gestire gli hidden e nascondere i post finiti sull'aggregatore.

Per tradurre i nuovi article types, che altrimenti compariranno nella seguente forma [articletypes.xxx] correggere il seguente file: etc/bundles/adminlocal.properties e dal pannello di controllo, funzioni di Super User, cliccare su "reload bundles, logging and producers".

Aggregare i feed di un nuovo nodo locale

Come dicevamo il nodo locale fornisce all'aggregatore i feed dei propri contenuti suddivisi per categorie. All'aggregatore non rimane quindi altro da fare che pescare i feed dagli indirizzi forniti e inserire i contenuti letti dentro il database dove verranno "prodotti" e pubblicati.

L'aggregazione di un nuovo nodo locale consta nell'inserimento di un nuovo record del tipo [articletype.xxxxfeed] nel database

Gli articletype disponibili sono:

• [articletype.localfeaturefeed] per le feature locali dei nodi
• [articletype.features_internazionali_feed] per le feature internazionali dei nodi
• [articletype.features_nazionali_feed] per le feature nazionali dei nodi
• [articletype.localcommentifeed] per le analisi dei nodi locali
• [articletype.localnotiziefeed] per le notizie dei nodi locali
• [articletype.localcomunicatifeed] per i commenti dei nodi locali
• [articletype.localrassegnefeed] per le rassegne/repost dei nodi locali
• [articletype.localhiddenfeed] per i post nascosti dei nodi locali

Quindi se un nodo locale YYY.indymedia.org deve essere aggregato dovrà fornire un URL per ognuna delle categorie sopra elencate. Dopodichè l'admin dovrà inserire nel database un nuovo "articolo" per ogni categoria di feed (new article nella pagina principale) specificando nel menù a tendina l'articletype corretto (vedi lista sopra).

Nel long title del form specificherà il nome del nodo, (es. Indymedia YYY, Indymedia ZZZ ecc...).

Nel campo location specificherà l'URL del feed fornito dal nodo locale per la categoria da aggregare (Es. http://YYY.indymedia.org/rss.xml?region=locali&type=feature)

Nel campo Web address specificare il link al nodo (es. http://YYY.indymedia.org/)

Abstract: inserire 2.0

Flaggare l'articolo published e salvare.

A questo punto l'aggregatore è informato dell'esistenza di un nuovo nodo da aggregare con le informazioni su dove reprire i feed. L'operazione di richiesta dei feed avverrà secondo le modalità definite nei Job (vedi sezione) che verranno lanciati manualmente o per effetto dei Cron.

Accorpare i feed multipli

All'aggregatore giungono i contenuti dei nodi locali sotto forma di feed che vengono pubblicati sul newswire. Uno dei problemi in cui si incorre è che all'aggregatore possono arrivare dei post identici quando lo stesso post viene pubblicato su diversi nodi locali.

Per evitare quindi che il newswire venga ingolfato da post identici gli admin dell'aggregatore raggruppano i post identici sotto un unico post. Questo nel newswire è immediatamente riconoscibile dall'icona modificata sul newswire che indica due documenti sovrapposti.

La procedura per raggruppare i post identici, di modo che venga indicato nel post un unico testo con i link agli articoli pubblicati dai nodi locali (per non perdersi gli eventuali commenti pervenuti), è la seguente.

a) L'admin individua il numero identificativo del primo post "multiplo" pervenuto sull'aggregatore. Il numero in questione è visibile nella barra di stato del browser in rollover sul "preview" dell'articolo.

b) Nell'interfaccia di admin, dalla schermata principale, inserire l'id dell'articolo nel campo "open article" per editare l'articolo in questione.

c) Una volta aperto in editing l'articolo inserire nel campo "Address:" la stringa AGGREGATOR. Poi si salva il post modificato. Questo indicherà all'aggregatore che questo post è il post che comparirà nel newswire e che conterrà i riferimenti ai post degli altri articoli che invece verranno tolti dal newswire perchè identici a quest'ultimo.

d) Una volta definito quindi qual è il post che funge da "base" dobbiamo indicare all'aggregatore quali sono gli altri post da raggruppare. Quindi con la stessa tecnica determiniamo l' id del post e lo editiamo. In questo post però non dovremo specificare il campo Address: bensi cliccare sul link "select" in basso a sinistra nella pagina di edit, associato alla chiave "Parent". In pratica dobbiamo indicare al post in questione qual è il suo "genitore" a cui essere raggruppato.

e) Cliccato il link select si aprirà un elenco di post. Ordinatelo secondo il criterio già impostato "newest first" in modo che all'inizio compaiano gli ultimi post pervenuti.

f) Ora selezionate l'id del post che avete impostato come "base" del raggruppamento. Tornate poi con il pulsante "start" alla schermata principale di admin.

g) Ripetete la procedura dal punto d) n volte quanti i post da accorpare al post "base"

h) Ripetete la procedura dal punto a) ogni volta che dovete prendere alcuni post e raggrupparli in uno solo

Aggiungere una nuova sezione

Produrre un file "statico"

Nell'interfaccia di admin andare sotto "new article". Verremo indirizzati sulla pagina per inserire un nuovo articolo. Nel menu a tendina "Article Type:" selezionare [artilcetypes.static] (finchè non verranno tradotte le voci appariranno in questo modo...)

Inserire il titolo dell'articolo, che comparirà nel testo dell'articolo e il testo "Content:" e nel "Context title" inserire il nome della pagina così come verrà richiamata dal menù.

Ad esempio se vogliamo introdurre una voce di menù che si chiama "Contatti" e che si riferisce ad una pagina contatti.shtml genereremo un file statico con i suoi contenuti e nel Context title inseriremo la parola 'contatti' (notare l'assenza dell'estensione di file).

Una volta lanciato il Job "staticpages" verrà prodotta una pagina (contatti.shtml) che Mir depositerà nella cartella dei file statici, da cui potrà essere richiamata dal menù (Es. <...href="/it/static/contatti.shtml">Contatti<...)

Se dovete ritoccare il menù e i suoi link occorre andare a modificare il file topmenu.template sotto etc/producer. Si tratta del template che viene incorporato nelle pagine, come il menù di navigazione. Quindi un eventuale inserimento di un nuovo link con relativa pagina statica associata nel menù dovrebbe essere accompagnata da una modifica nel suddetto template.

Traduzioni article types

Seguono le traduzioni proposte (e attualmente applicate) per i feed nel pannello di admin

• [articletype.localfeaturefeed] Feed feature locali
• [articletype.features_internazionali_feed] Feed feature internazionali
• [articletype.features_nazionali_feed] Feed feature nazionali
• [articletype.localcommentifeed] Feed commenti newswire
• [articletype.localnotiziefeed] Feed notizie newswire
• [articletype.localcomunicatifeed] Feed comunicati newswire
• [articletype.localrassegnefeed] Feed rassegne newswire
• [articletype.localhiddenfeed] Feed hidden

Cose di cui tenere conto e correggere

• Nell'aggregazione delle features e nel newswire dei nodi "nuovi" gli item arrivano nell'aggregatore tutti con la stessa data di pubblicazione, che è la data "attuale" perchè corrisponde alla data di primo inserimento dell'item nel database dell'aggregatore. Finora sono stati corretti a mano le date delle features appena aggregate in blocco con le loro date di pubblicazione reali così come pubblicate sui nodi locali. L'effetto è che alla prima aggregazione di un nodo locale, le fetaures e il newswire del nodo appariranno tutte come emesse al momento stesso dell'aggregazione e si posizioneranno in testa negli spazi adibiti alla pubblicazione (anche se in realtà hanno già mesi di vita).

• Per implementare il meccanismo del rating (che forse non verrà nemmeno utilizzato) e per una scorretta valutazione del ruolo dei feed nella quadripartizione dei file, la suddivisione nelle quattro aree è fatta attraverso l'utilizzo di una tabella d'appoggio che lega l'identificatore dell'item con quello dell'area di appartenenza. Alla luce dei nuovi sviluppi di indymedia italia questo passaggio risulta inutile e sarebbe meglio quindi riportare l'implementazione di Mir alla sua forma originale per non comprometterne future estensioni o upgrade.

to top