[LibreStream] Lenguaje de Implementación de la Plataforma

[Alejandro Pérez]

Opino igual que Paco, aunque yo lo dividiría en etapas, pensar en una
solución minimalista, es la mejor forma de llevarnos de 0 a una version
0.0.X.

Es decir creo que deberíamos recoger todas las ideas y establecer cuales
son posibles de inmediato, a mediano plazo y a  largo plazo.

Por ejemplo la discusión sobre que framework, que tipo de
identificación, las pondría como después de que podamos realizar un
broadcast y el steaming en html, luego algo de php para llevar un
sistema de usuarios y poder contar sesiones, es decir podamos 10
personas verle la cara al que esta haciendo el streaming.
Entonces vemos las opciones de framework y demás detalles, de nada sirve
tener algo en drupal, rails etc. si no podemos hacer el streaming
básico.

Lo que me lleva al siguiente punto, la tecnología a usar David menciono
una, creo que requerimos documentación para ir familiarizándonos, por
favor deja los links por aquí on en la wiki.

On Mon, 2012-01-30 at 10:36 -0500, David Narvaez wrote:
> 2012/1/30 Paco <paco at 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
> _______________________________________________
> Librestream mailing list
> Librestream at listas.floss-pa.org
> http://listas.floss-pa.org/cgi-bin/mailman/listinfo/librestream