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.

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

Traduzioni article types

• [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

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.

Linee guida dell'aggregatore

Questo consegna all'aggregatore 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 contribuisce a nessuna selezione dei post, non può cancellare, nascondere ne editare i post pervenuti. 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

Per ogni tipologia di feed deve essere specificato l'URL relativo. 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> ...

• 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

Aggiornare la feature principale

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 special 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 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

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'.

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<...)

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

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 unpost 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.

Articles / tipologie di articoli

Alcune considerazioni sull'utilizzo di Mir di Indy Italia

Al nodo locale spetta anche il compito di decidere se un post vada hiddato 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:

• La feature introduttiva, qualora non pervenga tramite feed, se consensuata dalla lista può essere introdotta manualmente nel sistema da un amministratore.
• L'accorpamento dei post multipli, qualora arrivassero dai nodi locali più post uguali, deve essere fatto da un utente admin che prende il post da aggregare (il primo pervenuto) collegando ad esso i rimanenti affinchè l'utente venga informato della presenza di altri post (con relativi commenti) su diversi nodi locali.
• L'introduzione di nuovi "topics" e nodi locali da cui prelevare i feed da pubblicare (sempre su richiesta consensuata di lista)
• La normale gestione utenti e/o le usuali operazioni di manutenzione

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

Aggiungere una nuova tipologia di articolo (es. relazioni, inchieste, dossier, ecc...)

Aggregare i feed di un nuovo nodo locale

Accorpare i feed multipli

Aggiungere una nuova sezione

Produrre un file "statico"

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.

Per le note base si veda il riferimento architettura Mir

Il comportamento dei job quindi può essere configurato attraverso questo file. Si prenda ad esempio il producer.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 producer.xml quindi, modificando il valore della key _limit_ da 10 a 50 ridefinirà il limite nel ciclo Enumerate sottotante e consentirà 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.

Non è stata scritta nessuna riga di codice in Java

L'interfaccia presenta sulla sinistra la lista dei producer ddisponibili. 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 sua particolarità consiste nell'essere un CMS che non produce pagine "On the fly" ma pagine statiche che possono essere separate su diversi server.

Generazione Manuale (job)

La "generazione manuale" qui sta ad indicare che questi job possono esser lanciati manualmente. Di norma, essendo Mir un produttore di pagine statiche, i job verranno lanciati da un processo cron che ogni tot minuti 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.

Segue l'elenco dei job di Indy Italia

• 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)

ImcItalyIndymediaMir

Table of content :

Mir

Architettura di Mir

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

Interfaccia gestione di Mir

Login

Pannello di controllo

Generazione Manuale

Articles

Navigation

Static Images

Startpage

Media

Getloalfeatures

Getlocalcomunicati

Getlocalrassegne

Getlocalcommenti

Getlocalnotizie

Getlocalhidden

Staticpages

Add/Edit article

Media

Article / tipologie di articoli

Funzioni di Super Utente

Gestione aggregatore

Come faccio a:

Aggiungere una nuova tipologia di articolo (es. relazioni, inchieste, dossier, ecc...)

Aggregare i feed di un nuovo nodo locale

Accorpare i feed multipli

Aggiungere una nuova sezione

Produrre un file "statico"