[LibreStream] Lenguaje de Implementación de la Plataforma

Mon Jan 30 16:31:36 UTC 2012

Paco,

Creo que en un inicio no tendríamos que llevar cuentas de usuario, pero
en el largo plazo si, seria bueno saber quien usa la plataforma, para
que la la usa etc, ya veré un par haciendo streaming subido de tono
(porno), eso ya pasa hasta en ustream.
Ademas que tenemos que llevar canales de cuantos streams se realizan a
la vez secciones de en modo visor etcs

On Mon, 2012-01-30 at 11:10 -0500, Paco wrote:
> Yo voto por php con framework cake https://en.wikipedia.org/wiki/CakePHP (más
> que todo porque rima con caka)
> 
> Con respecto a lo de reinventar la rueda, si es como lo pienso no habrá
> necesidad de llevar cuentas, ni base de datos ni nada, la comunicación va del
> portal a la red social o a un buffer temporal), la única entrada del usuario
> sería el textbox de comentarios, y filtrar eso es fácil en cualquier lenguaje...
> 
> Saludos
> 
> 
> On Mon, Jan 30, 2012 at 10:51:13AM -0500, Alejandro Pérez wrote:
> > 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
> > 
> > 
> > _______________________________________________
> > Librestream mailing list
> > Librestream at listas.floss-pa.org
> > http://listas.floss-pa.org/cgi-bin/mailman/listinfo/librestream
> 