[LibreStream] Lenguaje de Implementación de la Plataforma

Mon Jan 30 16:10:57 UTC 2012

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

-- 
Paco
http://www.linuxlatino.org/