Site icon ZoomingIn

Quando l’Open source si Scontra con i Protocolli Chiusi

OpensourceCominciamo 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:

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.

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.

Exit mobile version