[LibreStream] Lenguaje de Implementación de la Plataforma

[David Narvaez]

2012/1/30 Paco <paco en linuxlatino.org>:
> Yo opino que html/php estaría bien, sin frameworks ni nada, no creo que sea
> necesaria tanta cosa.

Así empiezan todos los problemas :)

> Pero, mi idea de lo que será la interfaz web puede ser minimalista (favor
> confirmar):
>
> * Desde el punto de vista productor:
>  - Autenticar el usuario
>  - Capturar cam y video
>  - Proveer con un link de la tranmisión
>
> * Desde el punto de vista del visitante:
>  - Ver la transmisión con el link que elproductor publica
>
> En principio eso me parece aceptable y no veo la necesidad de usar nada extra,
> ahora si lo que se busca además de lo anterior es:

Es de hecho un punto medio entre lo de arriba y lo de abajo. Es decir,
todo lo de arriba va, y ver los comentarios abajo para lo que también
va.

> * Desde el punto del productor:
>  - Llevar un registro con las transmisiones realizadas y grabación de las
>    mismas

No sé si sea necesario. ¿Tal vez para poder medir popularidad? De esa
manera podríamos llevar la cuenta de cuántos usuarios vuelven, etc.
Nos sirve para hacer análisis y marketing, supongo.

>  - Recibir comentarios (y almacenarlos) de usuarios

Almacenarlos no. Lo que va a tener la interfaz es un text box donde
poner comentarios, y esos comentarios se van a la cuenta ligada a la
transmisión (e.g., si estás usando tu cuenta de  Identi.ca para la
transmisión, tus comentarios se van para allá) o algo así entiendo que
tiene UStream.

>  - Suscribirse a otros usuarios y ser notificado cuando inician transmisión

No había pensando en este feature y me parece interesante. ¿Qué dice
el resto? Lo que veo complicado aquí es que si yo uso una o varias
cuentas externas para transmitir y no hay un mapping a cuentas
internas (porque la plataforma no maneja cuentas) entonces no sé a qué
se suscribiría la gente. Tal vez al final habrá que manejar cuentas
internas, entonces.

>  - Permitir y aceptar basado en una lista de control de acceso los usuarios que
>    pueden o no ver y ser notificados de transmisiones
>  - Realizar transmisiones privadas en las cuales sólo los usuarios autenticados
>    y aceptados por el productor para dicha sesión podrán verla

Creo que estas dos son lo mismo desde el punto de vista de
implementación, y por ahora no va a ser un feature de LibreStream.

> * Desde el punto del visitante:
>  - Poder dejar comentarios en tiempo real con el productor (mensaje privado) y
>    resto de visitantes (mensaje público)

Lo mismo que los comentarios de arriba.

>  - Suscribirse a productores para ser notificado vía email cuando inicien
>    transmisiones públicas o aquellas privadas en las que es agregado

Las mismas consideraciones de arriba.

>  - Poder ver en modo offline transmisiones pasadas

No, no vamos a estar guardando las transmisiones.

>  - Ver y mantener perfiles e interactuar con otros miembros, escribiendo
>    mensajes en su "canal/wall" inbox privado, etc

Depende de si habrá o no cuentas internas.

> Entonces para cosas así sí sería bueno tener un framework o partir de una base
> que ya nos brinde muchas de esas funciones, drupal o django o la hipstersada del
> momento.
>
> Todo depende que tanto se quiera lograr.
>
> También es importante estar consiente que si se usa una base como drupal o
> similar hay que ir actualizándola a medida que los autores la actualicen y casi
> seguro dichas actualizaciones no tendrían mucho efecto (beneficioso) para la
> aplicación. Lo cual terminará en: o nos estancamos con una versión drupal vieja
> o nos aburrimos de actualizar componentes que funcionan bien.

Estoy muy de acuerdo con eso. Yo creo que si usamos todo un framework
para manejar cuentas internas y OAuth, entonces toda la funcionalidad
adicional del framework no importa y podríamos no actualizarlo jamás.
Pero si LibreStream se hace como un módulo de Drupal, entonces es
necesario adaptar LibreStream a las siguientes versiones de Drupal a
medida que rompen el API de módulos.

> Si hacemos todo nosotros (ya sea usando un framework o no) los cambios que se le
> harían a la interfaz serán todos de tipo bugfixes o nuevos features... stuff
> that matters ;)

Pero tendríamos que reinventar un par de ruedas como cuentas de
usuario y seguridad (XSS, SQLI, etc)

David E. Narváez