[LibreStream] Lenguaje de Implementación de la Plataforma

Mon Jan 30 16:13:19 UTC 2012

Contestando tarde pero contestando,  mientras menos dependiente lo hagamos
mejor en mi opinion, Drupal, a futuro, un módulo que intregrue.

Pienso que usar un framework sería lo ideal por  ahora, django o algún o de
php, algo con ruby no creo, hay librerías suficientes en ruby para un
proyecto como este?

Saludos,

2012/1/30 Alejandro Pérez <alejandro.perez.torres at gmail.com>

> 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
>

-- 
Diego Tejera
http://diegotejera.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listas.floss-pa.org/pipermail/librestream/attachments/20120130/fd5e2c9a/attachment-0001.html>