Valoración del artículo:Entras las características que hacen interesante a WebSockets se encuentra la promesa de ofrecer una API simple para comunicar con el servidor así como la posibilidad de que estas comunicaciones sean bidireccionales, es decir, que puedan iniciarse en el lado del servidor; todo ello con una mejora en la latencia que actualmente soportan esta clase de comunicaciones.
Sin embargo, para Diciembre de este año tanto Firefox como Opera habían, finalmente, implementado WebSockets (desde la versión 10.70 en Opera y desde la Beta 7 de Firefox 4), desdiciéndose de algún modo de sus palabras previas. Sólo la gente de Internet Explorer mantenía su idea original: esperar a una versión más estable de la especificación.
Esta vulnerabilidad es lo suficientemente grave como para haber llevado al equipo de Firefox y Opera a deshabilitar su implementación sobre WebSockets. La gente de Chrome y Safari aún no se habían pronunciado al respecto al momento de redactarse este artículo, aunque dada la gravedad del asunto no se esperaba otra reacción diferente que la que han tomado otros fabricantes.
Estos desarrolladores se encontrarán, a partir de esta semana, con que casi ningún navegador va a seguir ofreciendo soporte a WebSockets, con lo que deberán reprogramar sus aplicaciones web. Aquellos que hayan utilizado la detección de características y se hayan apoyado en Java y Flash en los casos en que el navegador no implementara la tecnología tampoco habrán resuelto el problema puesto que estarán confiando en una implementación igual de insegura que la que sufren los navegadores, y que no sería de extrañar que también termine siendo desactivada en breve.
Algunos han decidido tomárselo con humor, haciendo circular por la Red un vídeo de humor al respecto de lo que está pasando con WebSockets. Otros, probablemente, no se lo han tomando con tanta filosofía.
Quizás para poder comprender mejor porqué se ha llegado a este punto, deberíamos re-examinar el concepto de estándar. En un artículo anterior desgranamos los pasos que se tienen que seguir para que una especificación se convierta en Recomendación por parte del W3C, es decir, el estado de estándar. Obviamente los fabricantes de navegadores no pueden esperar a este estadio último para empezar a implementar la especificación en su software, pues de lo contrario tampoco se alcanzaría nunca el nivel de Recomendación, dado que es necesaria la existencia previa de dos implementaciones interoperables entre sí.
Sin embargo, muchos fabricantes de navegadores se han lanzado últimamente a una carrera por ser el que "más soporta los estándares" que les ha llevado a implementar especificaciones que, como WebSockets, no era más que un borrador de trabajo susceptible de todo tipo de modificaciones. La propia implementación que de WebSockets ha hecho Chrome ya había sufrido un cambio muy importante meses atrás, consecuencia de una de las revisiones que de WebSockets estaba haciendo su equipo de trabajo.
Y es precisamente balancear entre la prontitud a la hora de implementar una especificación susceptible de convertirse en estándar y la estabilidad suficiente para no hacer la vida más difícil a los desarrolladores de aplicaciones web, lo que debemos exigir a los fabricantes de navegadores. Nosotros no debemos ser, de nuevo, las víctimas de un nuevo escenario de "guerra de navegadores" en la que la amenaza de "no ser compatible" se convierta en arma arrojadiza entre Apple, Google, Microsoft, Mozilla y Opera.
Otra posible solución es el ejercicio de su responsabilidad por parte de los fabricantes de navegadores, como generador de un soporte de plataforma como son, a la hora de implementar nuevas características. En concreto algunas voces piden que, cuando un fabricante decida "arriesgarse" e implementar una especificación que no está cerca de ser estable, lo haga bajo su propio etiquetado. Es decir, que las APIs correspondientes lleven un prefijo que las identifiquen unívocamente como propias del vendedor, al no estar respaldadas por ningún estándar. En Microsoft, por ejemplo, han seguido esta aproximación a la hora de implementar la API que sirve para medir los tiempos de carga de una aplicación web.
De este modo, un desarrollador que haga uso de esta API sabrá, sin género de duda, que esta tecnología es propia de Microsoft, puesto que no existe realmente un estándar maduro que la abale ni se tiene porqué esperar que los demás fabricantes de navegadores vayan a incluirlas de la forma en que Microsoft las ha implementado.
Compartir en redes sociales
 enrique... | Imparcialidad | 04/1/2011 |
| Los "Estandares" Que no son tan estadar | 04/1/2011 |
Usuarios: 
15 de December de 2010
