Tengo algunos inconvenientes con Silverlight... a ver si me puedo explicar:
"...algunos les cae mal M$..." A mí no es que me caiga mal M$, es que voy a apostar a una tecnología que está absolutamente bajo control de un "monopolista convicto", ya conocido por sus numerosos lockins... Si viniera Microsoft con un Silverlight que sea una especificación que cualquiera puede implementar sin ningún tipo de restricción (**ningún** implica que no tienen manera de limitarme de ninguna manera [1] tanto hoy como siempre), y me pongo como ejemplo (un developer sólo en su casa, se puede armar una implementación de la especificación sin que siquiera M$ se entere); en ese caso, sería una tecnología a evaluar. Técnicamente, no creo que Silverlight aporte mucho. "...y seguramente Linux..." Eso no lo sabemos aún, tengo entendido. Aún así, como requisito de entrada, le exijo que mejore lo que ofrece hoy Flash (que si bien pueden decir que "soportan Linux", sólo lo hacen en una única plataforma --x86-- y de manera menos que satisfactoria -- admito que la versión 9 mejoró mucho en esto último -- y encima es propietaria, lo que más allá de los problemas éticos, es un problema para el mantenimiento por parte de las distribuciones). "...algun tipo de plugin para las RIAs..." Esto limita la audiencia... y en el caso de que no la limite, ¿realmente queremos que el 99.9999% de las computadoras tengan instalado un plugin propietario de una compañía?. Si no es propietario, ¿por qué no incluirlo, como base standard, en el browser (en lugar de ser un plugin)? "...usando el XAML..." (1) desconozco si es un standard libre, nunca leí que sea de libre utilización, mientras que las tecnologías que reemplaza (al menos HTML+JS+CSS, no me meto con la parte de Workflow, que básicamente no nos interesa), sí lo son; (2) no me consta que realmente sea "mejor" que el triplete mencionado... y si lo es, ¿qué necesidad había de crear un nuevo pseudo-standard? ¿no podemos seguir con un HTML5 / 6 / ...? Si ya tenemos años de experiencia con los problemas conocidos de esta tecnología, ¿por qué nos metemos con una nueva, inmadura, que (te garantizo) tiene una nueva raza de problemas aún por resolver? Estaríamos desperdiciando todo lo que invertimos en HTML+JS+CSS... "...sometiendonos a las implementaciones..." Eso lo leo como si no preferiríamos que exista una única implementación (lo que evitaría la falta de uniformidad que te preocupa). La respuesta es fácil: NO. Prefiero un standard que cumple con el criterio que ya mencioné, aunque inevitablemente produzca implementaciones (algunas intencionalmente) de mala calidad. Creo que estamos en condiciones de haber aprendido y no volver a caer en una falsa implementación del standard (ejem, IE) devorando el mercado para retrasar el progreso. Quiero dejar en claro: la única manera de que haya innovación es si cualquiera compite con cualquiera por mérito, no por user base o cuenta en el banco [2]. En definitiva, mi criterio de evaluación, es que cualquiera pueda crear una implementación en cualquier condición que ejecute toda aplicación que esté construída acorde al standard (las excepciones deben ser por motivos técnicos, y no artificialmente creadas por M$ para favorecerse aprovechando su posición de mercado). Para hacer esto, M$ no necesita ni enterarse (mucho menos poder prohibírmelo). Hoy y por siempre. Un modelo son las licencias libres (entiendo que lo que M$ llama "licencia" es un contrato, ya que involucra al menos dos partes), en la que existe una única parte que renuncia, bajo ciertas condiciones, a derechos otrora otorgádoles por leyes de Copyright... Es una declaración abierta "quien quiera puede hacer esto si respeta esto otro". Pero renunció a esos derechos (no puede saltar mañana cambiando las reglas de juego). [1] Puede agregarme condiciones (como por ejemplo lo hace la GPL) en cuanto a redistribución. En ese caso, se analizan esas condiciones (la de la GPL es más que razonable). Y todavía me quedan pendientes las potenciales "extensiones" propietarias al standard por parte de M$. Mi hipotética implementación debería poder correr razonablemente aplicaciones construídas usando las herramientas y el runtime de M$. Esto creo que excluye la incorporación de un códec de video patentado... [2] Ironía: XMLHTTPRequest fue inventado por M$ en IE :). Lo sé, irrelevante, pero llamativo... PD: Me encantaría leer a algún proponente de XAML y Silverlight (que sea pensante e independiente, los que hay dando vueltas no me sirven...). Yo, por mi parte, no le veo ni un pelo de positivo... PD2: ¿Fui muy severo? No quiero sonar como un fanboy, pero no veo ni una pizca de cambio en la actitud de M$ (lo que, me parece totalmente entendible, siendo que una compañía se debe primero a sus accionistas y no a sus clientes... esto conflictúa con los requerimientos que yo le pido). Saludos, Nacho On 5/4/07, Federico Brubacher <[EMAIL PROTECTED]> wrote:
Hola, se q es offtopic y q algunos les cae mal M$ pero queria saber sus opinones sobe Silverlight antes WPF/E ahora q van a ver Plugins para WIndows, OSX y seguramente Linux. El tema q me preocupa o en realidad quiero debatir es si realmente vamos por el buen camino usando CSS + AJAX y sometiendonos a las implementaciones de los engienes de javascript de nuestros browsers y de CSS ... (sobre todo el palo es para nuestros clientes q usan IE no nuestro amado Firefox). Digo quizas sea mejor usar algun tipo de plugin para las RIAs, Flex sonaba bien pero habia q programar en la bosta de actionscript, ahora q podemos porgramar en la plataforma .NET (inclusive en Ruby si gustamos) me parece q puede tomar fuerza lo de RIAs con plugins (en conrtaste de las de AJAX).Finalmente Silverlight tiene varias ideas buenas como la base para una buena interaccion entre programadores y disenadores usando el XAML. Noc uds diganme ... Saludos -- Federico Brubacher www.fbrubacher.com Colonial Duty Free Shop www.colonial.com.uy Traful Lufthansa City Center www.traful.com/uy _______________________________________________ ruby mailing list [email protected] http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar
_______________________________________________ ruby mailing list [email protected] http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar
