Contestando tarde pero contestando, mientras menos dependiente lo hagamos mejor en mi opinion, Drupal, a futuro, un módulo que intregrue.<div><br></div><div>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?</div>
<div><br></div><div><br></div><div>Saludos,</div><div><br><br><div class="gmail_quote">2012/1/30 Alejandro Pérez <span dir="ltr"><<a href="mailto:alejandro.perez.torres@gmail.com">alejandro.perez.torres@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Opino igual que Paco, aunque yo lo dividiría en etapas, pensar en una<br>
solución minimalista, es la mejor forma de llevarnos de 0 a una version<br>
0.0.X.<br>
<br>
Es decir creo que deberíamos recoger todas las ideas y establecer cuales<br>
son posibles de inmediato, a mediano plazo y a largo plazo.<br>
<br>
Por ejemplo la discusión sobre que framework, que tipo de<br>
identificación, las pondría como después de que podamos realizar un<br>
broadcast y el steaming en html, luego algo de php para llevar un<br>
sistema de usuarios y poder contar sesiones, es decir podamos 10<br>
personas verle la cara al que esta haciendo el streaming.<br>
Entonces vemos las opciones de framework y demás detalles, de nada sirve<br>
tener algo en drupal, rails etc. si no podemos hacer el streaming<br>
básico.<br>
<br>
Lo que me lleva al siguiente punto, la tecnología a usar David menciono<br>
una, creo que requerimos documentación para ir familiarizándonos, por<br>
favor deja los links por aquí on en la wiki.<br>
<div class="HOEnZb"><div class="h5"><br>
On Mon, 2012-01-30 at 10:36 -0500, David Narvaez wrote:<br>
> 2012/1/30 Paco <<a href="mailto:paco@linuxlatino.org">paco@linuxlatino.org</a>>:<br>
> > Yo opino que html/php estaría bien, sin frameworks ni nada, no creo que sea<br>
> > necesaria tanta cosa.<br>
><br>
> Así empiezan todos los problemas :)<br>
><br>
> > Pero, mi idea de lo que será la interfaz web puede ser minimalista (favor<br>
> > confirmar):<br>
> ><br>
> > * Desde el punto de vista productor:<br>
> > - Autenticar el usuario<br>
> > - Capturar cam y video<br>
> > - Proveer con un link de la tranmisión<br>
> ><br>
> > * Desde el punto de vista del visitante:<br>
> > - Ver la transmisión con el link que elproductor publica<br>
> ><br>
> > En principio eso me parece aceptable y no veo la necesidad de usar nada extra,<br>
> > ahora si lo que se busca además de lo anterior es:<br>
><br>
> Es de hecho un punto medio entre lo de arriba y lo de abajo. Es decir,<br>
> todo lo de arriba va, y ver los comentarios abajo para lo que también<br>
> va.<br>
><br>
> > * Desde el punto del productor:<br>
> > - Llevar un registro con las transmisiones realizadas y grabación de las<br>
> > mismas<br>
><br>
> No sé si sea necesario. ¿Tal vez para poder medir popularidad? De esa<br>
> manera podríamos llevar la cuenta de cuántos usuarios vuelven, etc.<br>
> Nos sirve para hacer análisis y marketing, supongo.<br>
><br>
> > - Recibir comentarios (y almacenarlos) de usuarios<br>
><br>
> Almacenarlos no. Lo que va a tener la interfaz es un text box donde<br>
> poner comentarios, y esos comentarios se van a la cuenta ligada a la<br>
> transmisión (e.g., si estás usando tu cuenta de Identi.ca para la<br>
> transmisión, tus comentarios se van para allá) o algo así entiendo que<br>
> tiene UStream.<br>
><br>
> > - Suscribirse a otros usuarios y ser notificado cuando inician transmisión<br>
><br>
> No había pensando en este feature y me parece interesante. ¿Qué dice<br>
> el resto? Lo que veo complicado aquí es que si yo uso una o varias<br>
> cuentas externas para transmitir y no hay un mapping a cuentas<br>
> internas (porque la plataforma no maneja cuentas) entonces no sé a qué<br>
> se suscribiría la gente. Tal vez al final habrá que manejar cuentas<br>
> internas, entonces.<br>
><br>
> > - Permitir y aceptar basado en una lista de control de acceso los usuarios que<br>
> > pueden o no ver y ser notificados de transmisiones<br>
> > - Realizar transmisiones privadas en las cuales sólo los usuarios autenticados<br>
> > y aceptados por el productor para dicha sesión podrán verla<br>
><br>
> Creo que estas dos son lo mismo desde el punto de vista de<br>
> implementación, y por ahora no va a ser un feature de LibreStream.<br>
><br>
> > * Desde el punto del visitante:<br>
> > - Poder dejar comentarios en tiempo real con el productor (mensaje privado) y<br>
> > resto de visitantes (mensaje público)<br>
><br>
> Lo mismo que los comentarios de arriba.<br>
><br>
> > - Suscribirse a productores para ser notificado vía email cuando inicien<br>
> > transmisiones públicas o aquellas privadas en las que es agregado<br>
><br>
> Las mismas consideraciones de arriba.<br>
><br>
> > - Poder ver en modo offline transmisiones pasadas<br>
><br>
> No, no vamos a estar guardando las transmisiones.<br>
><br>
> > - Ver y mantener perfiles e interactuar con otros miembros, escribiendo<br>
> > mensajes en su "canal/wall" inbox privado, etc<br>
><br>
> Depende de si habrá o no cuentas internas.<br>
><br>
> > Entonces para cosas así sí sería bueno tener un framework o partir de una base<br>
> > que ya nos brinde muchas de esas funciones, drupal o django o la hipstersada del<br>
> > momento.<br>
> ><br>
> > Todo depende que tanto se quiera lograr.<br>
> ><br>
> > También es importante estar consiente que si se usa una base como drupal o<br>
> > similar hay que ir actualizándola a medida que los autores la actualicen y casi<br>
> > seguro dichas actualizaciones no tendrían mucho efecto (beneficioso) para la<br>
> > aplicación. Lo cual terminará en: o nos estancamos con una versión drupal vieja<br>
> > o nos aburrimos de actualizar componentes que funcionan bien.<br>
><br>
> Estoy muy de acuerdo con eso. Yo creo que si usamos todo un framework<br>
> para manejar cuentas internas y OAuth, entonces toda la funcionalidad<br>
> adicional del framework no importa y podríamos no actualizarlo jamás.<br>
> Pero si LibreStream se hace como un módulo de Drupal, entonces es<br>
> necesario adaptar LibreStream a las siguientes versiones de Drupal a<br>
> medida que rompen el API de módulos.<br>
><br>
> > Si hacemos todo nosotros (ya sea usando un framework o no) los cambios que se le<br>
> > harían a la interfaz serán todos de tipo bugfixes o nuevos features... stuff<br>
> > that matters ;)<br>
><br>
> Pero tendríamos que reinventar un par de ruedas como cuentas de<br>
> usuario y seguridad (XSS, SQLI, etc)<br>
><br>
> David E. Narváez<br>
> _______________________________________________<br>
> Librestream mailing list<br>
> <a href="mailto:Librestream@listas.floss-pa.org">Librestream@listas.floss-pa.org</a><br>
> <a href="http://listas.floss-pa.org/cgi-bin/mailman/listinfo/librestream" target="_blank">http://listas.floss-pa.org/cgi-bin/mailman/listinfo/librestream</a><br>
<br>
<br>
_______________________________________________<br>
Librestream mailing list<br>
<a href="mailto:Librestream@listas.floss-pa.org">Librestream@listas.floss-pa.org</a><br>
<a href="http://listas.floss-pa.org/cgi-bin/mailman/listinfo/librestream" target="_blank">http://listas.floss-pa.org/cgi-bin/mailman/listinfo/librestream</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Diego Tejera<br><a href="http://diegotejera.org" target="_blank">http://diegotejera.org</a><br>
</div>