ChannelWeb | Blog

Video sul web, CoDec e Container

Thu, 28 Apr 2011 13:35:23 +0200

Alcune note sulla digitalizzazione dei media, in particolare sulla distribuzione dei materiali video.

In questo documento si elencano le opzioni disponibili e consigliate su quali Container e CoDecadottare per la creazione dei file da pubblicare online e distribuire attraverso supporti digitali di contenuti audio/video (AV)

CoDec e Container

Le tecnologie di codifica e archiviazione dei contenuti multimediali sono in continua trasformazione.
Non esiste al momento e non è prevista per il futuro prossimo un’unica combinazione di Container e CoDec supportata dalle diverse piattaforme tecnologiche (OS+player o browser).
Per rendere contemporaneamente disponibile un contenuto AV a tutti i device e piattaforme, è necessario creare molteplici versioni del contenuto codificate in file diversi.

Fatta eccezione per i video eseguiti tramite Adobe Flash™ (che può eseguire la combinazione H262/AAC/MP4 dalla versione 9.0.60.184), per cui è richiesta l’installazione di un plugin o di un software apposito (per esempio YouTube x iPhone), questa è la tabella di compatibilità per browser e device disponibili nel futuro prossimo:

Codec/Container	IE	FIREFOX	SAFARI	CHROME	OPERA	IPHONE	ANDROID
Theora+Vorbis+Ogg	·	3.5+	†	5.0+	10.5+	·	·
H.264+AAC+MP4	9.0+	·	3.0+	·	·	3.0+	2.0+
WebM	9.0+*	4.0+	†	6.0+	10.6+	·	2.3

* Internet Explorer 9 supporterà WebM solo con un’installazione a parte del CoDec (Microsoft non distribuirà il CoDec con l’OS o il browser)
† Safari interpreta correttamente quello che QuickTime è in grado di riprodurre: QuickTime ha il supporto nativo soltanto per H.264/AAC in MP4.

In definitiva, per compatibilità sono necessari:

una versione container WebM, video VP8 e audio Vorbis;
una versione container MP4, video H264 baseline video e audio AAC “low complexity”;
una versione container OGG, video Theora e audio Vorbis.

Con questa combinazione è possibile supportare tutti i moderni browser e device tramite un meccanismo di fallback a catena fino al video player basato su Adobe Flash™.
Per i contenuti “solo audio”, basta derivare un subset di quanto elencato sopra:

una versione Vorbis;
una versione AAC “low complexity”;

Costi di licenza
Licenze e brevetti per H264 e AAC (coperti da brevetti internazionali).
Il consorzio MPEG-LA è titolare della gestione della licenza del CoDec H264 - http://www.mpegla.com
MPEG-LA ha un portfolio complesso per la licenza d’uso del CoDec e distingue in due categorie i produttori di strumenti di codifica/decodifica e i distributori di contenuti: per entrambe le categorie sono previsti costi annuali e per pezzo/contenuto.
Gli gli altri contenitori citati, WebM, OGG e codec Theora, Vorbis sono invece open source e non ci sono problemi di patent pending.

Per ulteriori informazioni

sezione sul sito ufficiale di Mpeg-LA - http://www.mpegla.com/main/programs/AVC/Pages/Intro.aspx
articolo su StreamingMedia.com a proposito del sistema di licenza di Mpeg-LA; http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/The-H.264-Licensing-Labyrinth-65403.aspx

Anche per l’uso del CoDec audio AAC – anch’esso coperto da brevetto internazionale – sono previsti costi di licenza, ma con una tabella più semplice da interpretare.

pagina specifica sul sito di VIA Licensing - http://www.vialicensing.com/licensing/aac-fees.aspx

BEdita, semantic content managment framework

Wed, 13 May 2009 15:04:00 +0200

Prima beta scaricabile del nostro progetto

Dopo due anni di duro lavoro (in collaborazione con Chialab) abbiamo finalmente pubblicato e rilascato la prima beta pubblica con licenza open source del progetto BEdita: un framework per creare applicazioni Web pensato per il Web2.0, che ambisce a diventare uno strumento di riferimento per il prossimo Web3.0 e per il futuro Web Semantico

La beta scaricabile la trovate su http://www.bedita.com/be-download

Framework o CMS?

BEdita presenta molte analogie con i cosiddetti CMS (Content Management Systems) e spesso è presentato così per semplicità, ne rispetta infatti (almeno in parte) la definizione: a tool that enables technical and non technical staff to create, edit, manage and finally publish a variety of content (such as text, graphics, video, documents etc). Con la differenza che lato publishing non fornisce volutamente una soluzione di default finita e univoca.

Una buona definizione di framework software ci può aiutare a capire meglio: a framework is incomplete, though concrete, driving solution to recurring high-value problem. In questo senso BEdita è:

incomplete – non è uno software che da solo risolve un problema/bisogno di un utente; piuttosto è un potente strumento per [web]designer/[web]developer che vogliono creare applicazioni frontend;
driving solution to recurring high-value problem – è utile in tutte le situazioni in cui debba costruire un'applicazione (frontend) in cui è necessario gestire contenuti complessi e multimediali, e le loro relazioni semantiche; evita a un designer/developer di dover affrontare e risolvere tutte le tipiche problematiche correlate.

Architettura e principali features

A livello architetturale gli elementi fondamentali del semantic framework sono due:

un'applicazione Web di backend per la redazione dei contenuti e delle loro proprietà e relazioni semantiche, con un'interfaccia utente innovativa per l'ergonomia tramite l'associazione cromatica fra tipologie di oggetti, l'uso estensivo del drag'n'drop e altre tecniche AJAX;
un API di frontend, servizi e specifiche per creare applicazioni frontend; con interfaccia Web in prima battuta, ma anche desktop/mobili sfruttando, per esempio, l'interfaccia nativa REST/XML.

L'applicazione backend è unica ed è la medesima per ogni installazione del sistema o istanza, le applicazioni frontend sono costruite tramite un'API ed ereditano dal core del sistema classi Model e business logic: possono essere poche linee di codice PHP o strutture più complesse. Questa separazione è una scelta fatta per ragioni di sicurezza, efficienza, scalabilità e per lasciare maggiore libertà possibile al lavoro del designer/developer.

Riassiumiamo di seguito le caratteristiche/features più interessanti del sistema nel suo complesso:

internazionalizzazione completa: gestione di contenuti e interfaccia utente in qualunque lingua (tutte le lingue definite dallo standard ISO-693-3 sono in teoria supportate) – lato UI è utilizzato il formato gettext, mentre per oggetti/contenuti è stata creata una struttura dati dedicata;

sistema a oggetti: ogni tipo di contenuto dentro BEdita è un oggetto, che può essere taggato, categorizzato, tradotto, geolocalizzato; quindi non solo documenti, ma anche immagini, video, eventi, schede anagrafiche, gallerie multimediali, newsletter...
estensione oggetti: possibilità di creare nuovi tipi di oggetti, possibilità di aggiungere proprietà custom tipizzate agli oggetti stessi;

modularità: moduli software specifici per task e tipi di contenuti differenti (cioè multimedia, events, news, administration, publishing, addressbook, newsletter,...)

posibilità di creare relazioni semantiche libere fra oggetti;

sistemi di autenticazione interno o esterno/pluggable tipo LDAP o OpenID;

gestione integrata di sistema di newsletter (modulo dedicato);

statistiche redazionali, integrazione di statistiche con sistemi come Google analytics, Piwik e log del web server (apache logs);

granularità di accesso: definizione dinamica di gruppi di utenti con accesso in lettura/scrittura ai singoli moduli software;

interfaccia XML/REST e JSON nativa per gli oggetti pubblicati;

ogni oggetto è identificato da un nome proprio alfanumerico detto nickname che può essere usato nelle URL e applicazioni frontend per referenziarlo; è l'equivalente semantico dell'ID;

Il Web compie 20 anni, e non li dimostra

Sun, 15 Mar 2009 12:24:59 +0100

Nel marzo del 1989 a Tim Berners Lee venne un'idea...

Sembra passato veramente tanto tempo dal marzo 1989 quando un ricercatore del CERN di Ginevra propose un documento intititolato: Information Management : a Proposal.

In questo documento proponeva "a large hypertext database with typed links", e non riscosse un grande successo all'epoca (beh, capita spesso alle buone idee).

Per il primo sistema Web funzionante bisognerà aspettare la fine del 1990 quando Berners Lee mise in piedi: un Web server, un browser, il prodocollo HTTP e le prime pagine HTML che descrivevano il progetto stesso....

Qui troverai approfondimenti sul primo server Web.

Ora il Web è diventato uno strumento importante nella vita di tutti i giorni per moltissime persone: ma è ancora sottoutilizzato, usato male e fondamentalmente non compreso appieno .... insomma c'è ancora davvero tanto da fare.... siamo solo all'inizio! :-)

Nota: è bello notare come una figura come Berners Lee non sia poi diventata una specie di popstar, è sempre rimasto dietro le quinte a lavorare e ha preso la parola solo su argomenti veramente importanti (vedi Net Neutrality e Semantic Web). E proprio in questi giorni si è espresso chiaramente in difesa della privacy sul Web. Grazie Tim!!

Quante licenze Open Source? Ne bastano 4

Tue, 17 Feb 2009 01:06:52 +0100

Anzi due. Parola di Bruce Perens.

In un bell'articolo che invito tutti a leggere Bruce Perens affronta il classico problema di quale licenza Free/Open Source scegliere per il proprio progetto.

Esprime bene quello che penso da parecchio tempo, ovviamente lo fa molto meglio di quanto potrei fare io...

In breve il problema è questo: ci sono tante licenze Free/Open Source (più di 70) nate per scopi differenti; tutte rispettano i principi del Free Software e dell'Open Source; non tutte sono della stessa qualità; molte possono creare conflitti: se devo combinare più software con licenze differenti potrei semplicemente non farcela o complicarmi parecchio la vita. Che fare?

Semplice. Per chi fa business con il software Free/Open Source Perens individua due obiettivi tipici:

to get everyone possible to use your software to do things the same way (per esempio, se vuoi promuovere un formato/protocollo affinchè diventi uno standard)
to create a partnership for software development, where everybody shares in the work (cioè creare un ecosistema collaborativo attorno al tuo progetto/prodotto e far si che un possibile concorrente se ne possa anche avvantaggiare ma sia costretto a condividere miglioramenti e correzioni apportate al software)

Per raggiungere al meglio questi obiettivi i consigli sono:

una licenza permissiva come The Apache License 2.0 simile alle licenze MIT e BSD, ma con una protezione migliore dai brevetti (obiettivo: maggiore uso/penetrazione del software);
una licenza per condividere con delle regole come la GPL 3, evoluzione delle licenza GPL, criticata per delle clausole anti-DRM che per Perens sono invece fra i suoi punti di forza (obiettivo: permettere un ampio uso ma costringere a collaborare sull'evoluzione del software);
una licenza via di mezzo come LGPL 3 che consente di creare soluzioni proprietarie, ma richiede di rendere disponibili eventuali migliorie/correzioni;
una licenza Affero GPL3 pensata per condividere con delle regole (sharing-with-rules) anche il software tipicamente usato via rete: vedi applicazioni Web (ma non solo) in primis.

Quest'ultima licenza vuole evitare che il Google di turno si prenda il tuo software e lo usi senza condividere le modifiche: la GPL classica richiede la condivisione del codice unicamente quando il codice è distribuito, ma il Google di turno non redistribuisce software, pubblica servizi. Questa licenza equipara l'utilizzo di un servizio via rete (vedi: usare una Web application come GMail) alla distribuzione del software: il Google di turno è obbligato a rendere disponibili le sue modifiche per il solo fatto di pubblicare sui suoi server un servizio basato su quel software.

E' la stessa licenza che abbiamo scelto per il nostro Semantic Content Management Framework BEdita, fa piacere notare che Perens avrebbe preso la stessa decisione.....

Per concludere le licenze consigliate sono di fatto solo due: The Apache License 2.0 e GPL 3 . Le altre due (LGPL3 e Affero GPL3) sono solo variazioni della GPL3.

Sono tutte licenze compatibili fra loro e (SOPRATTUTTO) sono state studiate e revisionate parola per parola da decine e decine di avvocati delle aziende più grandi al mondo.

"No license anywhere has had 1/10 of the legal review that went into GPL3."

Quindi perchè non usarle? E perchè mai inventarsene di nuove?

XPS, attacco all'altro monopolio, part 1

Fri, 14 Nov 2008 14:22:36 +0100

Ovvero quando Microsoft decide di entrare nei terreni consolidati e presidiati da Adobe Corporation.

Con il lancio di Vista™, la Microsoft (MS, ma quella 'mmericana) ha presentato due nuovi "standard suoi": Silverlight per la pubblicazione di contenuti multimediali e vettoriali su Web e XPS per la fruizione di contenuti paginati orientati alla stampa.

Perché Silverlight™ e XPS sono i concorrenti diretti di due "standard" de facto: il formato di file SWF (Adobe Flash™, Flex™, ecc…) e il formato PDF (Adobe Acrobat™ e tante altre robe). Oggi tocca a...

XPS

La MS ha sviluppato XPS (XML Paper Specification, nome in codice “metro”) in cooperazione con altre IT companies: come in parte recita il nome, “specifiche per la carta in XML”, è il set di specifiche tecniche di un linguaggio basato su XML per documenti paginati (cartacei e non), indipendenti da piattaforme software e periferiche I/O: le pagine del documento possono contenere testo e grafica, e il loro aspetto è consistente qualunque sia la stampante o il software di visualizzazione utilizzato. In pratica, un file XPS è un archivio zip contenente tutti i file di cui si compone il documento: un file XML per ciascuna pagina, il testo, i font, le immagini bitmap, grafica vettoriale 2D e le informazioni DRM (Digital Rights Management). In MS Vista™ il supporto a XPS è nativo: è utilizzato come formato di spool per la stampa, si possono creare documenti XPS tramite una apposita stampante virtuale (virtual XPS printer driver) ed è pre-installato un programma di visualizzazione come estensione del browser Internet Explorer 7 (XPS Viewer). Il viewer e il driver sono disponibili agli utenti di Windows XP tramite l'installazione di .Net Framework 3.0. Non riassumo le specifiche della tecnologia XPS, che potete naturalmente leggere altrove. Sta di fatto che la MS ha sottoposto dette specifiche al ECMA International per ottenere il riconoscimento dello standard internazionale (committee TC46). E poi la licenza è un capolavoro di comunitarismo già nel nome, Community Promise for XPS, e dispone che sia royalty free e liberamente ridistribuibile.

XML VS PDF

Il formato PDF (Portable Document Format) non bisogna certo di presentazioni. Certo XPS nasce come suo concorrente diretto:

Sia XPS che PDF possono essere usati come formato di visualizzazione, scambio e stampa di documenti.
Entrambi mirano a descrivere pagine fisse, ovvero di precise dimensioni e il cui contenuto non cambia aspetto e disposizione con la piattaforma di visualizzazione.
Sia XPS che PDF possono essere usati come linguaggi di descrizione della stampa e comunicazione con le macchine stampanti. Per esempio, così come a PDF si accompagna il formato JDF (Job Definition Format) per la descrizione del flusso di lavoro, XPS è dotato dei “Print Tickets” che, seppure con qualche differenza, implementano un'applicazione simile.

Certo, PDF ha i vantaggi di

essere da anni uno standard di mercato, soprattutto nella grafica;
essere molto conosciuto e largamente utilizzato;
avere una enorme libreria di software dedicato;
essere davvero cross-platform, dal momento che è utilizzabile su qualsiasi sistema, dai grossi server ai palmari

Ma è vero anche che XPS

è realmente completamente gratuito;
è basato su XML e compressione zip, quindi è facile e poco dispendioso implementare software dedicato;
è distribuito con il sistema operativo più diffuso del pianeta;
anche se Adobe Corporation è una gigantesca holding potente ed influente, la Microsoft è ancora più grande, più potente e, ça va de soi, più influente.

Continua...

(con Silverlight™, attacco all'altro monopolio - parte II)

Nomi di dominio “internazionalizzati”

Mon, 10 Nov 2008 11:22:56 +0100

L'internazionalizzazione dei nomi di dominio in 6 mosse (o poco più)

La questione se la sono posta i non occidentali (naturalmente) già una decina di anni fa.

Dunque da allora ad oggi:

Il principale problema consisteva nell'impossibilità pratica di riprogettare l'intera struttura dei DNS;
Dopo qualche anno di dibattiti, nel 2003 è stato definito lo standard "backward compatible" IDNA (Internationalizing Domain Names in Applications): un'applicazione IDNA compatible è in grado di effettuare conversioni dalla rappresentazione "restricted ASCII" a quella "non-ASCII" e viceversa (per es. un browser Web usa la versione restricted-ASCII per interrogare il DNS, ma presenta l'URL in lingua madre nella barra degli indirizzi);
Da allora sono accettati i domini IDN (Internationalized Domain Names), che sono tutti quelli composti esclusivamente da labels a cui si può applicare con successo l'algoritmo IDNA di conversione "ToASCII";
Dal 2004 già in Giappone si potevano registrare nomi di dominio internazionalizzati con estenzione .jp, successivamente anche i .info;
Solo nel novembre 2007 un gruppo di lavoro dell'ICANN ha iniziato a lavorare agli altri TLD delle varie nazioni;
Nel marzo 2008 infine l'IETF ha fondato un gruppo di lavoro per aggiornare il protocollo IDNA.

Detto questo resta che:

Tutti i moderni browser fanno la traduzione tramite l'algoritmo IDNA citato e sono dunque compatibili: Mozilla 1.4 (con Firefox), Netscape 7.1, Opera 7.11 e Safari.Internet Explorer 7.0 e le URL APIs di Windows Vista offrono supporto nativo agli IDN; non è compatibile Internet Explorer 6 (ma esiste un plugin).
C'è un grosso problema di sicurezza legato all'uso di omografi/omoglifi in situazioni di phishing o, meglio, per quello che è chiamato "homograph spoofing attack".Per esempio questo link che segue

http://www.pаypal.com

non vi porta al sito di paypal, perché al posto del carattere latin 1 "a" (Unicode U+0061) è stato usato il carattere cirillico "а" (Unicode U+0430), visivamente uguale.
L'esempio vale per tutti i numerosi casi di somiglianza tra lettere o ideogrammi, etc...
L'esempio citato è stato fatto dal gruppo Shmoo alla conferenza hacker Shmoocon, http://www.shmoo.com/idn/.
(NB: dal novembre 2005, per sicurezza, Firefox riporta nell'URL il risultato della traduzione tramite l'algoritmo citato ToASCII)

Per finire:

Si possono usare domini internazionalizzati, ma la comunicazione avviene attraverso l'uso dei relativi convertiti tramite l'algoritmo citato IDNA ToASCII e succede tutto a livello di browser (o in generale di applicazione client, ovvero il server manco lo sa che a lui è associato un nome Unicod-izzato/Internazionalizzato, perché lui è configurato per funzionare con la versione ASCII del medesimo dominio);
Niente è definitivo, se ne discute ancora e il protocollo sarà aggiornato; ma sicuramente non si abbandonerà la compatibilità verso il basso.

~/.bash_history

Mon, 10 Nov 2008 04:30:44 +0100

Introduzione all'uso dell'history in Bourne Shell

Ho appena letto di M.F. - utente Linux - che, avendo creato un programmino per inviare SMS da shell, ha poi trovato prova inconfutabile delle proprie corna in ~/.bash_history: una relazione di sei anni, con tanto di promessa di matrimonio e progetti prolifici (by etimo), si frantumava contro un |less.

Pare poi che M.F. non possa vivere senza di lei e dunque, avendo letto tutti gli espliciti sessuali negli SMS inviati dalla fedifraga a terzo, ha scambiato un newsgroup di Gentoo per "La posta del cuore" e ha - seriamente, miseramente, pateticamente - chiesto consiglio a una manica di smanettoni menefreghisti. E mi sa tanto che non è colpa della tipa...

Ma se l'history ha portato tanto dispiacere a M.F., può portare altrettanto e più diletto a tutti noi. Vi mostro come.

> history

Vi mena giù tutti i comandi salvati automaticamente in ~/bash_history, preceduti da un numero progressivo di riga.

> history 10

Vi tira fuori gli ultimi 10. Ok, ma che me ne faccio dei numeri di riga? E' presto detto:

> !101

Esegue il comando alla posizione 101.

> !-3

Esegue il comando che compare 3 posizioni indietro partendo dal basso (conta a partire da 1, non da 0 come si aspetterebbe qualche esploratore di array

> !!

Richiama l'ultimo comando inserito, sinonimo di !-1. Poi ancora:

> !wh

Richiama l'ultimo comando che inizia per "wh...". Se non dovessi ricordare se l'ultimo era un who oppure un which, puoi sempre digitare CTRL+r e iniziare a scrivere una qualunque porzione del comando: mano mano che scrivi, per magia, si materializzerà l'intera riga.

Pausa. Vi siete scaldati? Perché ora arriva la parte divertente.

Innanzitutto una sostituzione veloce sull'ultimo comando eseguito, ^string1^string2^.

Per esempio:

> find . -anme "*php" | wc -l
	find: invalid predicate '-anme'        [cazzarola!]
	> ^an^na^
	find . -name "*.php" | wc -l
	361

Il comando !, che da inizio ad una (cosiddetta) history expansion, supporta alcune opzioni precedute da : (due punti).

Si possono usare numeri interi per richiamare la n-esima parola nella riga richiesta. Per esempio:

> !cp:2

designa il secondo argomento dell'ultimo comando eseguito che inizia con "cp".

Al posto del numero, si può usare ^ per riferirsi al primo argomento, oppure $ per l'ultimo (!!:$ si può accorciare in !$).

Oppure ancora * per richiamare tutti gli argomenti.

Poi ci sono i modificatori.

Tra i più utilizzati: :p stampa il comando senza eseguirlo, :t se l'argomento è un lungo path prende solo la parte finale, :h, al contrario, rimuove solo la parte finale e prende il resto del path ("p" sta per print, "t" sta per tail, "h" sta per head).

Infine per evitare di conservare inutile ciarpame:

> export HISTIGNORE="&:ls:[bf]g:exit”

[non verranno conservati comandi duplicati, ls, fg, bg e exit].

Vi sembra troppo? State lì scettici a dire "ma chist'è scem'... chi caz se li ricorda?!". A mio immodesto parere, se li usate per un po', non ci rinunciate più.

Famo un esempio pratico articolato:

> cp ~/mytemplate.php /var/www/mysite/newfile.php
	> vi !$
	> cat ~/myfooter.txt >> !$
	> cd !$:h
	> svn ci !-2:$:t:p
	> !!

Ve lo spiego?

La prima è facile, copia quello da la' (la mia home) a la' (un'altra directory);
vi /var/www/mysite/newfile.php;
cat ~/myfooter.txt >> /var/www/mysite/newfile.php;
cd /var/www/mysite/;
svn ci newfile.php [ma stampa solo, non eseguire, ché non sono tanto sicuro...];
svn ci newfile.php [era giusto e lo eseguo davvero]

Bene.
Può bastare.
Anzi tre cose ancora:

rientra nell'uso dell'history anche cd -, che vi permette di saltare alla directory in cui eravate prima di un cd (comodo per fare avanti e'ndré).
l'history può costituire una falla nella sicurezza sotto molteplici aspetti (non solo per questioni di corna) e in particolare su sistemi multi-utente, ma la cosa va al di la' degli scopi di questo articolo.
un consiglio alla morosa di M.F.: un'altra volta, prima di lasciare zozzerie nel pc, lancia "unset HISTFILE" e la lista dei comandi inseriti sarà eliminata al logout. Poi MI puoi mandare tutti i messaggi che ti pare...

PHP debug con Xdebug/Eclipse/PDT

Wed, 08 Oct 2008 18:22:18 +0200

cinque semplici istruzioni per non perdersi nella configurazione di Xdebug/Eclipse/PDT

Tutti quelli che lavorano sul Web lo sanno: lo sviluppatore PHP è abituato (male) a debuggare a colpi di print/echo e compagnia, e talvolta gli piace anche! :-)

Ok, non è solo colpa del povero web developer, debuggare non è out-of-the-box come su altri linguaggi o piattaforme... (a meno di non usare IDE proprietari tipo Zend Studio)... ma ora.... siamo nel 2008, ci sarà un modo semplice per farlo usando strumenti open source? O vogliamo farci abbattere dalla frustrazione del print/echo/log e continuare a perdere un sacco di tempo???

Una soluzione integrata, efficace e libera è usare la combinazione Xdebug + Eclipse + PDT (il plugin per sviluppare in PHP che supporta anche il debugger Zend). In rete troverete un bel pò di materiale su come fare. In fondo al post troverete un paio di link utili. Non sto a riscrivere howto/tutorial già ben fatti, leggeteli... di seguito riassumo il tutto in 5 passi, con alcuni problemi comuni (e relative soluzioni) che tipicamente incontrerete. (ah... Eclipse+PDT li dovete già avere)

1. installate l'entensione Xdebug, su linux troverete qualcosa tipo php5-xdebug nel gestore di pacchetti, per win ci sono binari, per mac non so...per chi ha tempo e voglia si può sempre ricompilare; se avete installato il debugger Zend rimuovetelo, va in conflitto con Xdebug, quindi se pensavate di installarlo non fatelo! chiaro il concetto?.... e non dimenticate la cartolina! ;-)

2. configurate il modulo, prendete il php.ini che vi serve guardando la voce "Configuration File" nell'output di phpinfo() per script web o con php -i | grep "Configuration File" per script commandline CLI. Una configurazione di esempio è:

[XDebug]
zend_extension=/usr/lib/php5/extensions/xdebug.so
xdebug.remote_enable=true
xdebug.remote_host=127.0.0.1
xdebug.remote_port=9000
xdebug.remote_handler=dbgp
xdebug.profiler_output_dir=/tmp

ATTENZIONE per la voce zend_extension usate pathnames assoluti, ma soprattutto la voce da abilitare potrebbe non essere zend_extension ma zend_extension_debug o zend_extension_ts o ancora zend_extension_debug_ts; per capirlo guardate in phpinfo() o php -i le voci Debug Build e Thread Safety, quindi partire da zend_extension:

se Debug Build => yes , aggiungete _debug
se Thread Safety => enabled , aggiungete _ts

3. riavviate il web server e controllate l'output di phpinfo(), troverete "Zend Scripting Language Engine...with Xdebug 2. ...". Analogamente verificate sulla command line con php -i | grep "Xdebug" , gia' che ci siete verificate i moduli con php -m (no zend debugger, only xdebug!)

4. configurazione di eclipse PDT:

Window/Preferences/PHP/PHP executables: aggiungete una voce con path completo dell'eseguibile php CLI con php.ini relativo
Window/Preferences/PHP/Debug:Xdebug come debugger predefinito, come eseguibile quello definito sopra, e abilitate anche "Open in Browser" fra le workbench options

5. esegui il debugger, è arrivato il grande momento.... andate in "Run/Open Debug Dialog..." create nuove voci sul vostro progetto

PHP Script (solo PHP CLI): impostate Debugger (Xdebug), eseguibile PHP e file .php da debuggare (relativamente al worskpace); è comodo impostare "Break at first line" se non siete strasicuri del flusso di esecuzione, avrete un breakpoint alla prima riga
PHP Web Page: impostate Server Debugger (Xdebug), il file iniziale o principale della sessione (non sarà l'unico debuggabile ovviamente), "Break at first line" se preferite e attenzione: non usate URL Auto generate tipicamente Eclipse non conosce la vostra configurazione del web server... impostate a mano l'url principale del progetto
premete Apply e poi Debug...

A questo punto breakpoints, variabili, espressioni..... e mai più echo/print.. promesso?