MyTube: impersonalització local de YouTube

Després de la reunió d’avui, s’han pres un conjunt de noves decisions a partir de l’implementació realitzada fins el moment, que brinda oportunitats prou interessants que ens permeten “generalitzar” i/o preparar la aplicació perquè en un futur, sigui el mes escalable i interoperable possible.

Captures de les 4 noves linies comparatives entre implementació i reestructuració:

A grans trets doncs, es pretenen un set d’idees noves:

• Implementació amb un sistema de BBDD molt mes petit i senzill (menys potent) com per exemple SQLite, que permetria localment, gestionar una BBDD en un terminal telefònic per treballar amb videos grabats directament, per exemple. La BBDD, es a la que referencia el Data Loader i pròximanent, el crowler.
• Implementació modularitzada:

1. Mòdul MyTube, encarregat de gestionar completament el trafic de Requests per acabar generant un XML Feed particular per el client.
2. Mòdul Data Loader, encarregat de establir una comunicació asíncrona amb els clients que peticionin feeds, la BBDD per tal de recolectar material per generar el XML de filling i finalment, el Crowler de forma natural, per realitzar un filling de la BBDD de forma “semiautomatitzada”. Es preten crear un molt breu API de intercomunicació entre el Data Loader i el Crowler, per tal de gestionar diversos estats de la BBDD prèviament a realitzar les consultes de petició d’informació (SQL naturals).
3. Mòdul Crowler, que preten ser un petit aplicatiu existent o programat a voluntat amb un wrapper de PHP que s’encarregaria de realitzar el filling de la BBDD de videos de la forma mes inteligent possible. Es farà una aproximació del que seria usar una tecnologia com aquesta en el PFC. A més, s’implementarà una senzilla interface gràfica en PHP per a realitzar el filling manual de la BBDD també.
4. Mòdul configurador, per tal de poder establir paràmetres de funcionament de la aplicacio MyTube, generant un XML de propietats.

• Es preten disposar de la possibilitat de trossejar tant com sigui possible tots i cadascun dels components i a la vegada, poder mantenir-los completament junts en un punt particular. Es a dir, ha de ser perfectament redistribuïble.
• Independitzar el proxy/redirecting per filtratge (propi de un IPTABLES) del Content Manager, que seria el cor del aplicatiu. Donat que es una aplicació de tipus REQUESTING i depen d’un servidor actiu que li dona la lògica d’execusió (Apache en el nostre cas), haurem de minimitzar tant com sigui possible aquest cor d’execusió i independitzar-lo tant com es pugui. Per això, podem pensar en tecnologies mes senzilles com ara Cherokee o Lighttpd que son perfectament compatibles amb PHP i MySql o relatius.
• Volem a mes, disposar de la opcio de cambiar el mode voluntariament a nivell d’usuari, entre MyTube i Youtube natiu. S’implementarà a través d’un video switch.

De moment doncs, cal preparar tota la nova reestructuració de continguts.

El Data Loader, és aparentment, l’únic mòdul que no s’havia de desenvolupar en aquest projecte ja que quedava en mans d’un altre projecte final de carrera.

La idea bàsica, era la de disposar d’un servei (implementat per exemple via Web Service) que donada una query específica, retornes un set de dades per tal de poguer realitzar el filling dels feeds naturals desde el mòdul de generació de XML “XML Generator”.

Donada la no viabilitat de creació de projecte independent per a un mòdul d’aquestes característiques, he decidit implementar-lo jo a mode de servei natural, com a un mòdul mes dins del aplicatiu.

Evidentment, la gràcia escau en que aquest mòdul per complexe i independent com és, no podrà ser implementat dins del mateix paquet de l’aplicació final que anirà integrada en hardware empotrat donat entre d’altres particularitats, el constant accés a la BBDD que realitza i per tant, la necessitat de trobar-se físicament en una computadora servidora.

Així doncs, momentàniament esdevé flux natural de MyTube, però la implementació final, consistirà en independitzar-lo a una màquina servidora i habilitar-lo a mode de web service, per tal de poder realitzar crides POST via cURL desde MyTube, passant un set de paràmetres particulars per tal d’obtenir les dades per realitzar el filling del feed requerit.

El Data Loader doncs, pren com a paràmetre principal el tipus de feed, per tal de llençar contra la BBDD la query necessària i obtenir tota la informació referent a la petició.

Actualment, solament es retorna un sol vídeo. Falta aclarir com es controlarà la petició de un nombre màxim de vídeos (25 per defecte amb l’iPhone) i com es gestionarà el “next” per tal de carregar-ne un nombre X mes posteriors als obtinguts.

A mes, si el feed es de tipus “cerca”, s’envia un paràmetre posterior amb la cerca a realitzar contra títol i contra descripció dels vídeos.

Vegem doncs, un exemple de XML retornat per el Data Loader amb tota la informació referent a un video particular, posterior a peticionar un feed de cerca via la consulta “vivaldi“:

Es pot veure perfectament doncs, que conté tota la informació necessària per a realitzar el filling natural del feed demanat a través de les plantilles de YouTube.

El mòdul de XML Generator, usarà les plantilles de standard feed preguardades com a templates, per tal de omplir cada part amb les dades rebudes via Data Loader.

D’entrada, la part encarregada de generar XML d’informació segons petició de tipus de feed, quedava fora de l’àmbit del projecte donada la seva complexitat pròpiament.

Analitzant-la detingudament però, crec que és perfectament implementable dins d’aquest mateix projecte ja que facilita dues coses:

1) Poder manegar directament les dades d’una forma mes o menys precisa

2) Crear detingudament la classe “Data Filler” que ens permetrà generar XMLs amb totes les dades necessàries per a generar el XML Response segons els Templates dels Standard Feeds de YouTube API.

Per tant, presento doncs una estructura de la BBDD primària (aparentment no caldrà modificar-la gaire mes) que mapeja perfectament les dades que s’esperen dels videos per a la presentació dels XML Response.

edit: 21/04/2011 – revisió del esquema de BBDD.

Després de batallar durant dues setmanes llargues, sembla que tot torna a la normalitat i el funcionament torna a ser el esperat.

He hagut de canviar programació de lectura per STDIN per la classe Reader. Però realment sembla que la gent de YouTube han posat les coses a lloc, tot i afirmar que ells no havien canviat res…

Vaig apuntar-me al grup de debat de la API de YouTube i vaig aconseguir parlar amb en Jeff Posnick, que és bàsicament un dels principals developers de la API oficial.

El grup de debat és aquí:

http://groups.google.com/group/youtube-api-gdata/browse_thread/thread/9267774c46fb2e3a#

Van citar-me a més, un set de respostes a altres threads relacionats. Sembla que han estat casos aïllats, però casualment, no únics.

http://groups.google.com/group/youtube-api-gdata/browse_thread/thread/c5a0e7721544186e

En definitiva, el problema està resolt i espero que ja per sempre.

PD: el problema residia únicament amb un conjunt de feeds particulars (a excepció del de cerca natural) i solament succeïa en les condicions del projecte en sí, és a dir, si es sol·licitava normalment un feed desde la app de YouTube sense passar per proxys ni res estrany, tot funcionava com s’esperava, per tant, l’excusa fàcil esdevenia “mirat el teu router i la configuració del teu proxy, perquè nosaltres no hem fet res… Has de ser tu per nassos…”

Enmig d’una immersió programàtica, apareixen els primers problemes completament innecessaris:

- O Youtube amb els seus servidors, o Google capant “per motius externs”, provoquen que la lectura del STDIN per alguns dels FEEDS naturals sigui impossible, ja que les dades arriven tallades i incorrectes.

Crear aquesta espècie de “man in the middle” que estem fabricant, ara per ara solament es funcional per el cas de “Cercador” per paraula. Tots els altres feeds naturals (Recents, Mes Vists…) donen error.

He traquejat els accessos i observat el tràfic de xarxa via Wireshark i efectivament, les dades arriven “tallades”. Encara no se si es una mesura de seguretat per part de Google per tal de enviar les dades amb 2 o tres tirades i així evitar scripts intermitjos tipus el meu, o un error temporal que espero es resolgui aviat…

Afegir, que en cas de no activar el programa MyTube, el funcionament del app de YouTube del iPhone es el esperat. Per tant, mes que un error, pinta a “mesura aplicada” per part dels servidors de Google, i això, serà un bon problema!

Tot anava, i ara no.

No es “crucial” però si ens parem a pensar que en el fons, no necessitem per res el input de STDIN de YouTube, ja que ens encarregarem de generar-l’ho nosaltres. Tot i així es fa curiós veure com les coses canvien tant ràpidament…

Aviam que passa doncs…

Primera aproximació del desenvolupament:

Classes:

• Reader: encarregat de gestionar tot el tractament de la entrada estàndard (STDIN) i preparar les dades convenients.
• URL Parser: encarregat de realitzar el parsejat de la URL provinent de la REQUEST_URI contra el vector de servidor $_SERVER, i posteriorment, enviar l’ordre pertinent cap al generador de XML.
• XML Generator: rebent la correcte ordre del Parser, s’encarregarà de preparar i generar el XML de resposta “a la YouTube” (segons especificacions de la API oficial) omplint-lo però, amb informació provinent del Data Loader, que serà un objecte inclòs.
• Data Loader: fabricarem una aproximació d’entrada del que seria la classe final per se. Aquesta classe, a mode de peticionant, s’encarregaria de transmetre el missatge de petició de dades contra un servei que retornaria un XML formatejat amb tota la informació per accedir a les dades locals. Gracies a aquesta resposta, podríem interpretar-la i enviar les dades crues al XML Generator, que les usaria per a generar el XML resultant. El filling del Data Loader, es realitza en principi desde una BBDD que servirà per crear el XML de dades a enviar al Data Loader. En principi, aquesta tasca queda a banda del projecte i formaria part de un projecte altern d’un altre projectista que s’encarregaria de preparar les dades de filling.
• Writer: s’encarregarà de gestionar tota la comunicació i enviament de Responses al client local.

Excepcionalment:

- En fase encara de decisió, podria ser que decidíssim mesclar els continguts reals de YouTube amb els Locals, buscant una forma de compenetració entre els dos XML obtinguts i generats. D’aquesta tasca, s’en encarregaria una classe mescladora “Mixer”, que faria la feina de combinar totes les dades.

Impersonalització de YouTube a la xarxa local mitjançant l’implementació d’un Servidor Apache amb PHP fent ús de l’API oficial de Google.

El Projecte

Es pretén crear una impersonalització completa de YouTube a nivell local en primera fase que, a través de la creació d’una subxarxa interna degudament configurada, ens permetrà redirigir totes les peticions d’accés a YouTube cap a un servidor local Apache i programat en PHP, preparat per interpretar les comandes pròpies de la API oficial de YouTube de Google per tal de poder oferir continguts personals a través de les interfícies i clients existents actualment.

El nombre de clients d’accés a YouTube avui en dia es prou ampli i divers, des de el propi client web estàndard, fins a l’aplicació particular per a la gran majoria de telèfons de nova generació. Fins i tot, a través de Media-Centers i servidors de continguts digitals conjunts. Aquesta impersonalització doncs, ens permetrà un cop configurada degudament, usar la plataforma YouTube per servir els continguts locals especificats i pròpiament classificats.

El servidor a mes, farà transparent l’accés a YouTube a decisió de l’usuari i per tant, podrà oferir els continguts esperats en una determinada acció, a mes dels localment preparats.

Els beneficis resultants d’aquest projecte es basen en l’ampliació i fusió d’un parell de sectors que cada cop mes, formen part del dia a dia de molta gent: els continguts digitals personals + la plataforma YouTube en si mateixa com a aplicació d’èxit i ús massiu. Usant doncs una tecnologia existent, podrem servir per complet tot un ventall de continguts digitals concentrats en un mateix punt i no serà necessària la inversió de temps en dissenyar i crear una plataforma alternativa a una de mundialment acceptada i coneguda.

Objectius del projecte

• Dissenyar un sistema de re direcció via IPTABLES en hardware local en una subxarxa degudament configurada, via aplicació de router alternatiu o via configuració directe.

• Interpretar degudament les comandes de la API sol·licitades des de qualsevol client de YouTube existent, per tal d’implementar la programació pròpia del servidor local per atendre-les i gestionar-les segons toqui.

• Establir una estructuració completa de directoris i Bases de Dades per a l’emmagatzematge i col·locació de continguts locals. Decidir i dissenyar quins seran els mètodes d’accés, cerca i mineria de continguts segons les comandes interpretades.

Post-Objectius del projecte

• Establir un sistema de transcoding en temps real, per tal de permetre el servir qualsevol tipus de fitxer a nivell local.

• Envisionament de l’aplicació del projecte local a nivell remot, permetent al propi YouTube oferir la possibilitat de permetre als usuaris establir un set de directoris a ser interpretats i degudament minats per tal de fer nativa la capacitat d’oferiment de continguts locals.

La llista d’accions implementables per al projecte, és directament dependent a les capacitats de l’aplicació client al smartphone, iPhone.

Podrem pensar en desenvolupar tantes crides com aquest programa disposi, amb una accepció: no treballarem amb les accions que requereixin ser un usuari logat.

Es pot dir que les accions implementables, son justament aquelles que tenen relació directe amb la petició estàndard de feeds. El programa client, no permet realitzar parametritzacions complicades. En el fons però, son justament les accions mes comunes i les que mes ens interessen a l’hora de servir continguts locals i personalitzats.

Vegem doncs el llistat d’accions:

Llistat dels destacats

Llistat dels més vists

Avui:

Setmana:

Sempre:

Llistat per cerca a buscador

Llistat dels mes recents

Llistat dels mes valorats

Avui:

Setmana:

Sempre:

Llistat dels presents al historial

Per tant doncs, resumint les accions que tenim:

Implementables:

• Llistat de destacats
• Llistat dels més vists (Avui, Setmana, Sempre)
• Llistat de resultats per cerca a buscador
• Llistat dels més recents
• Llistat dels més valorats
• Llistat de presents al historial

No-Implementables:

• Llistat de favorits (preferits)
• Llistat dels meus vídeos
• Llistat de subscripcions
• Llistat de llistes de reproducció

Diagrama de casos d’ús del servidor local:

Diagrama de casos d’ús del servidor remot: