Quando l’Open source si Scontra con i Protocolli Chiusi

Cominciamo a spiegare un po’ di concetti base, un software spesso necessita di informazioni non residenti nella macchina su cui “gira”, ragion per cui ha bisogno di ottenerle sfruttando la rete (insomma, si collega a internet).

In particolare questo software dovrà contattare un computer remoto e porgli le giuste “domande” (richieste) per poter ottenere delle risposte. La forma (sintassi) con cui il server e il client dialogano viene, per l’appunto, chiamato Protocollo.

Dunque, in genere, chi costruisce il server ( e magari anche il client ) definisce anche un protocollo di comunicazione, cioè un linguaggio comune con cui scambiarsi informazioni.

Protocolli Aperti VS Protocolli Chiusi

Adesso che sappiamo cos’è un protocollo, passiamo a definire la differenza tra protocolli aperti e chiusi.

Un protocollo è detto aperto se colui che l’ha ideato ha pubblicato anche le specifiche (per semplicità diciamo che è la sintassi) con cui avvengono le varie comunicazioni tra client e server.
Un protocollo chiuso, invece, non prevede alcuna documentazione sul protocollo proprio perché sia client che server vengono sviluppati dalla stessa software-house. In genere è anche illegale sfruttare server con protocolli chiusi.

Il caso specifico MSN/Windows Live Messenger

Il protocollo che utilizza questo client di messaggistica è un protocollo chiuso, ciò implica che per poter scoprire il funzionamento dello stesso è necessario un processo di reverse engineering (si leggono i messaggi che vengono trasmessi/ricevuti da/verso server e si cerca di interpretare il funzionamento del protocollo) piuttosto complesso.
A complicare ulteriormente la situazione c’è Microsoft che aggiorna il protocollo una volta ogni 6 mesi circa, detto ciò mi sembra inutile spiegare quanto sia difficile stare al passo con i tempi nel progettare un Client alternativo di Messenger.

I Client alternativi a MSN/Windows Live Messenger

Il problema di base è che la piattaforma linux non è supportata da Microsoft, di conseguenza, si rende necessaria la creazione di un client alternativo che funzioni sotto linux.La scelta è davvero MOLTO vasta, ma preferisco citare i client più avanzati in termini di feature:

• Pidgin: multiprotocollo, ha pieno supporto per qualsiasi feature WLM ad eccezione di webcam/audio, ben integrato con gnome;
• aMSN: punta di diamante dei client alternativi (nelle ultime release supporta perfino webcam e audio), purtroppo MOLTO pesante per via delle librerie grafiche utilizzate (TCL/TK) e molto orripilante agli occhi;
• Emesene: (cercherò di essere imparziale, poichè collaboro al progetto) un client scritto in python, molto ben integrato con gnome e leggero.
  Nonostante ciò l’architettura è molto instabile, fatta male, e sostanzialmente incomprensibile nonchè mancante di adeguata documentazione, nelle ultime versioni (1.5 supportata dalla community e non dai developer principali) sono stati fixati MOLTI bugs e memory leak. Si prepara all’utilizzo di un sistema di supporto alla webcam un po’ più stabile. Fast file transfer non funzionante.

Il difficile futuro dei client alternativi Linux

Nonostante tutti questi progetti molto interessanti, esistono dei prototipi derivati dalle prime versioni di questi client, sto parlando di emesene2 e aMSN2.

• Emesene2: Promette molto bene (finalmente il codice comincia a diventare sensato), ma non ha alcun supporto peer-to-peer, ciò si traduce nella (momentanea) mancanza di supporto ad emoticon personalizzare, immagini personali, webcam, file transfer, audio.
  Punti di forza di questo client è l’alta modularità (addirittura è possibile sostituire interi moduli core o gui). Data di rilascio? Bella domanda, a mio parere non prima di marzo 2010.
• aMSN2: questo client fa ridere. Insomma doveva essere la “fusione” di pyMSN,emesene e aMSN, ma si è tradotto in una serie di specifiche.
  Tutti (o quasi tutti) gli sviluppatori di aMSN continuano a lavorare sulla prima versione del client, non fornendo alcun supporto a questa seconda versione che prevede: GUI per ogni Desktop environment (compresi Macosx e windows) e tutte le funzionalità di aMSN (versioni maggiori della 0.97). Ci tengo a precisare che questa “fantomatica” fusione si è quasi totalmente rotta a causa di incomprensioni e scelte progettuali che hanno fatto discutere tutti gli amministratori.

La soluzione

Sembrerà stupido, ma la soluzione è semplice: basta affidare ad un team di sviluppo (uno qualsiasi) la creazione di una libreria di protocollo scritta con un linguaggio basso livello (tipo ANSI C) e fornire i bindings per tutti i linguaggi.

Il vantaggio di avere questa libreria MANTENUTA DA UN TEAM DI SVILUPPO è duplice: da una parte sarà più semplice avere sempre l’ultima versione del protocollo MSN, dall’altra gli sviluppatori di client MSN non avranno più il vecchio e stantio problema di riscrivere da zero le funzionalità di protocollo.
La mia soluzione, difatti è già stata implementata (vedi pymsn=papyon) ma, a quanto pare, molti developer si rifiutano di volerla utilizzare…perchè preferiscono riscriverla da sè(?).

Insomma l’obiettivo è sare agli utenti linux un client di MSN, il problema è Il protocollo di MSN.
La soluzione?
Utilizzare una ed una sola libreria al fine di avere un buon supporto al protocollo.
Ma, a mio avviso, gli sviluppatori hanno perso da troppo tempo di vista l’obiettivo,quindi il problema, quindi la soluzione. In tal modo credo che dovremo aspettare ancora qualche mese (anno?) prima di vedere un client di MSN realmente funzionante sotto Linux.