El Blog

 
 

Calendario

<<   Agosto 2005  >>
LMMiJVSD
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31     

Últimos comentarios

Categorías

Sergey ¿qué pasó con lo de nosotros somos una "search company"?

Por RBA. - 22 de Agosto, 2005, 9:27, Categoría: General

Google saca hoy la beta (cómo no) de su Google Desktop 2. La cosa incluye una barrita vertical donde se le puede meter de todo: el tiempo, noticias, contenido sindicado, etc. Te permite añadir favoritos (bookmarks) y otras bondades.

Curiosamente sin embargo, la versión anterior se llamaba Google Desktop Search, y en esta versión le hay quitado la palabra consagrada, el quo-vadis de Google - ¡Search! - a cambio de un aburidito número 2. Ejem... Ya hay incluso quien dice que el trasto empieza a parecerse más a un navegador. ¡Sergey!

Y es que la moda ahora es especular sobre lo próximo que va a sacar Google. A nadie le importa un bledo lo que saque Microsoft, Yahoo o la vecina de abajo. Lo único que importa es cotorrear sobre lo que no sabemos, pero siempre y cuando sea "cosa Google". El resto es intrascendente. Y aunque yo soy de los que no le gusta meterse a lanzar predicciones o a alumbrar al personal con mis insípidas opiniones personales de lo que nos depara el futuro, voy a caer en la trampa y soltar un par de cosas que, sin pretender sentar cátedra alguna, sí es lo que me pasa por la cabeza cuando alguien me pregunta y me apetece dejarme en evidencia, bien hoy, bien conforme las cosas vayan tomando forma.

Techno..¿qué?
Uno de los rumores más curiosos es que Google vaya a comprar Technorati. Bien, no digo que no vayan a hacerlo, no soy yo quien maneja los billones de Google, pero para mí esa sería la compra más estúpida de Google hasta la fecha. ¿Por qué? Por un sencillo motivo. Google tiene en sus filas a un montón de programadores e ingenieros trabajando en una sola cosa: mejorar los algoritmos de búsqueda. Es la tecnología que mejor domina, y hasta la fecha, solo Yahoo le ha hecho frente con dignidad. Technorati por otra parte, solo tiene una cosa: una tecnología de búsqueda, que está empezando a sonrojar porque últimamente usar Technorati es una desesperación.

¿Para qué narices iba Google a comprar una empresa que lo único que tiene es una tecnología infinitamente inferior a la suya? No es que Technorati tenga una tecnología que Google no tiene, es que Google la tiene desde hace años, es su santo grial, y le dá patadas a la de Techonorati por todos lados.
 
Bien, Technorati tiene otras cosas: muchos blogs indexados y mucha gente usándolo. Creo que lo de indexar blogs no es algo que a Google le preocupe mucho - no solo indexa ya millones de ellos sino que llevar su tecnología de búsqueda y adaptarla a los sistemas de actualización vía ping, etc. es algo que pueden hacer ellos solitos sin ningún esfuerzo. Hablar de que mucha gente use Technorati creo que no es relevante considerando el número de personas que usan Google. Y "quitarlos" del escaparate para que no se los lleve otros, tampoco les hace gran favor, ya que quien se los lleve, no estará comprando precisamente una tecnología rompedora sino más bien una que necesitará mucho trabajo para enderezarla.

Ahora, si algún retrasado mental en Google piensa que sería muy chulo y quedaría muy bien comprar esa "cosa", pues ellos sabrán. En resúmen, yo no veo aquí un matrimonio que tenga sentido, aunque cosas peores se han visto. ¿Qué ves tú?

GOS, eso mejor después ¿no?
El otro rumor favorito es el futuro sistema operativo de Google. Es otra cosa que se me indigesta un poco. Yo, si fuese Google, no me iba a mojar en construir un sistema operativo, al menos no sin antes mojarme con otra cosa (que comento en un momento). No es que no pudiesen hacer uno muy bonito, pero montar un sistema operativo que llegue realmente a la gente y no solo a los geeks de turno, para empezar exige construir unas relaciones con cientos o incluso miles de fabricantes de software, de hardware, de PCs, OEMs, y un largo etc. que al menos yo lo veo como entrar en un terreno donde sinceramente, el empuje del éxito del buscador de Google no me parece ni de lejos suficiente para que dicha inversión se transforme en un éxito. Ahora bien, a Google le sobra el dinero, pues igual están así de locos.

Yo me considero bastante geek por lo que si se tiran a esa piscina, me daré un bañito con ellos, y es posible que el sueño de muchos googlers sea trasformar Linux (¿?) en un verdadero competidor en el mercado de sistemas operativos, y como lo que en Google sobra es el dinero y las ganas, igual se lo estan pasando bomba con el tema, pero como decía, antes de aventurarme en este espacio, yo haría otra cosa mucho más digestible y con mayores posibilidades de éxito que bien podría preparar el camino para ese sistema, lo haga quien lo haga.

Menos navegar y más innovar
¿Que qué cosa es esa? Pues otra también muy comentada. Algo que desde luego yo haría si tuviese el dinero y los recursos de Google. Un navegador. Pero no un navegador así como los que conocemos hoy, sino un navegador radicalmente diferente, capaz de realizar muchísimas cosas que los navegadores de hoy no pueden hacer.

Y no me refiero a cosas como Annotea o trabajos basados en la web semántica, sino un navegador que, aparte de soportar las tecnologías que hoy conocemos, ofrezca un entorno de desarrollo que nos permita a los programadores crear aplicaciones realmente interactivas, haciendo palidecer a las técnicas de AJAX que hoy están tan de moda. ¿Me seguís? Nada de aplicaciones basadas en JavaScript, Java, ASP, Flash, etc.

Si realmente el futuro a corto-medio plazo de Internet son entornos terriblemente dinámicos, dame una aplicación (navegador) que realmente me permita hacer cosas en esa dirección. Dame un "navegador" que gestione información entre mi máquina y la web de una manera que hoy es solo posible descargando un fichero, cargándolo en la aplicación de escritorio correspondiente, manejándolo desde esa aplicación, convirtiéndolo a tal o cual formato, etc etc. Los tan cacareados entornos de redes sociales dejarían de ser centralizados si dispusiesemos de un "navegador" que nos permita actuar como auténticos nodos, no como una pantalla de televisión que nos permita ser parte de una red según el canal en que estemos; el especulado futuro donde el ordenador de sobremesa actúa más como una terminal empezaría por ahí, con un navegador radicalmente diferente. Sin eso, yo no veo que se vaya a avanzar en ese sentido.

Sea lo que sea, insisto, si yo hoy tuviese el dinero y los recursos que hoy tienen empresas como Google, Microsoft, etc. en lugar de sacar un híbrido de Firefox o una nueva versión del IE soportando tabs y feeds, me pondría las pilas en crear una aplicación que realmente reinventa la manera en que hoy navegamos hasta tal punto que navegar sería tan solo una de sus múltiples funcionalidades.

Me entran ganas hasta de patearme - una vez más - la Sand Hill Road contándoles mi ocurrente idea ¿se apunta alguien? :-) Mejor no, que, al mismo tiempo que todo esto pueda parecer muy interesante, bien podría ser una tontería que no nos lleve a ninguna parte. Por el momento, seguiremos navegando, que tampoco nos vá tan mal así ¿verdad?

Permalink | 19 Comentarios | Referencias (2)
Etiquetas:

Comentarios

Antonio | 22 de Agosto, 2005, 11:03 | (Contacto, Página)
Estoy muy de acuerdo con que la compra de Technorati sería un error. No veo los beneficios por ninguna parte. Sobre los demás, son temas demasiado técnicos, no puedo opinar. Pero cada vez tengo más claro que Google se está dispersando, lo cual es bueno inicialmente, puesto que puedes pescar en más ríos desde el primer día. Pero al estar en todos los ríos empiezas a no conocerlos todos tan bien y a que ya no te consideren el mejor pescador del mundo mundial (eso es lo que eras cuando pescabas en un río que además, casi habías descubierto tú). La extensión de marca es muy peligrosa, nunca he sido gran fan de ella y Google está metido en ella hasta las cejas.

Narciso Cerezo | 22 de Agosto, 2005, 11:51 | (Contacto, Página)
Creo que en lo de comprar Technorati estaremos todos de acuerdo, pero en realidad ¿hay alguna diferencia con la compra de Blogger, por ejemplo? Me refiero a la utilidad que tiene para google o lo que le aporta.
Lo de entrar en otros mercados o no... pues es lo del ser o no ser. Por un lado está claro que el mercado es tan amplio que la única forma de llegar a algo es buscar un buen nicho y convertirse en el mejor en ese campo. Ahora bien, todo inversor te dirá que debes diversificar para garantizar tu futuro, porque lo que hoy es la bomba mañana deja de funcionar porque hay un nuevo adelanto que lo deja obsoleto o simplemente pasa de moda.
Google puede decir ya que es el mejor en las búsquedas, lo sea realmente o no esa percepción existe aunque sea de forma diferente según el mercado local (USA, España, LatAm, etc.). Entonces, y teniendo en cuenta que ahora tiene mucha pasta para invertir, quizás lo suyo es diversificar y buscar otros horizontes, siguiendo una línea lógica y sin olvidar su alma mater. Buen ejemplo de eso es Microsoft.
Respecto al navegador también estamos de acuerdo. Llevo muchos años haciendo aplicaciones "web" y creo que son sin duda el mejor vehículo por muchos motivos, pero la realidad es que aún les faltan capacidades, inherentes al modelo HTTP/HTML que estaba concebido para texto hipermedia y no para aplicaciones. Todo lo que ha salido son adornos para introducir mejoras y posibilidades, pero es hora de que alguien haga un "navegador" que permita a los desarrolladores explotar el verdadero potencial de la web.

Antonio | 22 de Agosto, 2005, 12:54 | (Contacto, Página)
Narciso, no puedo estar de acuerdo contigo. Obviamente, encontraremos ejemplos de lo que quieras, pero eso de

"Ahora bien, todo inversor te dirá que debes diversificar para garantizar tu futuro, porque lo que hoy es la bomba mañana deja de funcionar porque hay un nuevo adelanto que lo deja obsoleto o simplemente pasa de moda."

no lo comparto. Los inversores (entendiendo fondos de inversión, etc., no inversores estratégicos y a laaaargo plazo) quieren ganar dinero pronto y rápido. Para eso es bueno diversificar, pero no para el largo plazo de una empresa (insisto, esto es matizable, pero como regla general pienso que es así). Y lo de quedarse obsoleto por nuevos adelantos o modas es incorrecto. La necesidad de buscar y encontrar seguirá estando. Lo que hay que pensar no es que seamos una empresa con un website en el que buscar, sino una empresa de búsqueda. Hoy buscamos vía web y mañana con el teléfono y pasado mañana con una serie de selenitas (adoradores del queso, por cierto) que lo hacen por nosotros. Tu negocio es buscar, no "buscar con una página web". Si sabes ponerte al día en lo tuyo no tienes por qué desaparecer por un cambio de moda.

Narciso Cerezo | 22 de Agosto, 2005, 13:16 | (Contacto, Página)
Antonio,
Yo creo que las modas si afectan, por ejemplo en España Google está de moda y el uso de yahoo como buscador es muy bajo con respecto a Estados Unidos, por ejemplo. No creo que haya un motivo más allá de la moda en esta tendencia tan acusada.
Respecto a los cambios tecnológicos, depende del negocio del que hablemos, pero por lo general los negocios pasan por las dichosas etapas aquellas de "visionarios", "adoptadores tempranos", etc, hasta llegar al de "comodity" donde no suponen un valor añadido y sólo quedan tres o cuatro jugadores consolidados. Además de esto, cada cierto tiempo se producen cambios que provocan la desaparición de ciertos negocios, no es algo que suceda de hoy a mañana pero si razonablemente rápido. Lo de "no poner todos los huevos en la misma cesta" es algo muy antigüo.
Un ejemplo: Mercadona, una gran cadena de supermercados en España. Mercadona siempre ha sido "pionero" en implantar nuevas tecnologías, fueron los primeros de España con los códigos de barras y lo son nuevamente con RFID. El dueño de Mercadona, aunque no abandona ni descuida su negocio principal, tiene sin embargo otros negocios tan lucrativos o más, como uno relacionado con metales (fudición, estructuras metálicas, etc).
En este caso quien diversifica es el empresario, no la empresa, y cedo en que quizás es más adecuado que así sea, pero ¿por qué no puede ser la empresa la que diversifique?
En este sentido de diversificación empresarial, Microsoft, que nombraba antes es un gran ejemplo. Empezaron con el sistema operativo, que sigue siendo su "mother ship" y lo defienden a capa y espada, pero luego se han ido metiendo en mil cosas más, enlazando sabiamente desde el SO y siguiendo una línea más o menos razonable: office, herramientas de desarrollo, navegador, etc. El resulado creo que es magnífico desde el punto de vista empresarial, más allá de otras consideraciones filosóficas.
Me quedo sin espacio para seguir comentando... :) pero está resultando muy intersante el tema.

Joserra | 22 de Agosto, 2005, 13:27 | (Contacto, Página)
Si vemos que el modelo HTTP/HTML se queda corto para las aplicaciones que se ¿demandan? actualmente sobre la Web, la opción, es volver a aplicaciones cliente/servidor. El nuevo "navegador" sería más complejo obviamente, y haría tratamiento de datos más pesados que actualmente. En cuanto el navegador sea más pesado, dejaremos de hablar de web ¿no os parece? Serán aplicaciones distribuidas, simplemente.
Respecto a la diversificación de Google, yo creo que es interesante para todos nosotros que se dedique a diversificar su negocio, por el potencial de desarrollo que tienen. Está claro que el ser una empresa de "searches" no es lo que le da dinero, si no la utilización por millones de usuarios, y a esos es a los que deben sacar el máximo rendimiento (y dinero) de cualquier manera que se les ocurra.

swaze | 22 de Agosto, 2005, 13:47 | (Contacto, Página)
Las modas afectan, pero no tanto, si hoy se sigue usando mas Google en españa que yahoo, no creo que sea por moda sino por constumbre. En su dia Google estubo de moda y nos engancho a muchos, ahora bien, ya no es el boom que fue antes y aun asi sigue teniendo millones de usuarios, ¿por que? porque estamso acostumbrados a el, simplemente por eso.

Lo de diversificar lo veo bien,hasta cierto punto, ya se sabe lo que dicen, "estudiante de mucho, maestro de poco" pero creo que debe ser el empresario y no la empresa el que diversifique, y la razon es muy simple, tarde o temprano la empresa acaba estancandose y hundiendose, y mas en el mundo de la informatica, si se hunde por ejemplo el motor de busqueda de google, se esta hundiendo google, y afectara al resto de servicios (buenos o malos en eso no entro) que ofrecen, solo por ser Google, por el contrario si es el empresario el que diversifique, se puede hundir el motor de busqueda, Google, pero no afectara (por lo menos directamente) al servicio de email.

Por otro lado, yo estoy de acuerdo con vosotros en que la compra de Technorati seria el mayor error que podria cometer google. Y tambien opino que si intentaran hacer un SO fracasarian estrepitosamente, lo intentaran ahora o mas adelante, porque al fin y al cabo todos lso servicios que esta ofreciendo Google tienes algo en comun, son via web o pequeñas aplicaciones (entiendase por pequeña Picasa, Google Heart,etc), es su mundo y siguen un patron logico, hacer un SO es ir a lo grande y creo que, no es que no puedan o no sepan, es que se sale de sus tipos de proyectos.

Pero lo del navegador que proponeis, eso no solo es algo que deberia existir ya, sino que revolucionaria todo el mundo de internet y de los PC, dandole un nuevo significado, yo estoy deseando que aparezca ya jejeeje.

saludos

swaze

Narciso Cerezo | 22 de Agosto, 2005, 17:44 | (Contacto, Página)
Joserra, yo creo que no hablamos de volver a Cliente/Servidor, sino de volver a algo más similar al Terminal/Servidor.
Por poner un ejemplo de cómo lo veo yo, veamos por un momento como es y como podría ser un listado de resultados para una consulta.
Ahora, una forma típica de hacerlo es que tras enviar la consulta con un formulario, el servidor envía una página completa con la información de parte del resultado (una página). Pero no sólo envía los datos, sino todo el html necesario para el formato, los menús de la página, enlaces a la página siguiente y anterior, etc. Es decir, envía más información de la imprescindible. Además, el listado resultante no es tan funcional como el que tendrías en el explorador de ficheros, por ejemplo. Para conseguir parte de esas funcionalidades hay que trabajar más y sobrecargar más las páginas con scripts y otras historias haciendo cada página y cada autor una interfaz diferente, lo cual lleva a la confusión en los usuarios.
Ahora, imagina que en la página en cuestión, en vez de tanta historia pudiera poner algo así:

Y con ese trocito va el navegador y me pone un control de listado nativo del sistema operativo en el que resida, con sus botones de página siguiente, anterior, etc y se encarga de todo.
El resultado es que mi aplicación es mucho más ligera, más rápida de desarrollar, más amigable para el usuario y con una probabilidad de errores infinitamente mayor. Y sin perder ninguna ventaja de lo que me aporta la web.
Yo creo que no es precisamente ciencia ficción hacer algo así, pero requiere que se haga de la forma más estandar posible, y a poder ser que lo "adoptara" el w3c o similar.
No olvidemos que el navegador en si mismo es un "fat client", lo que es "thin client" es la aplicación web que corre en el.

Narciso Cerezo | 22 de Agosto, 2005, 17:45 | (Contacto, Página)
Joserra, yo creo que no hablamos de volver a Cliente/Servidor, sino de volver a algo más similar al Terminal/Servidor.
Por poner un ejemplo de cómo lo veo yo, veamos por un momento como es y como podría ser un listado de resultados para una consulta.
Ahora, una forma típica de hacerlo es que tras enviar la consulta con un formulario, el servidor envía una página completa con la información de parte del resultado (una página). Pero no sólo envía los datos, sino todo el html necesario para el formato, los menús de la página, enlaces a la página siguiente y anterior, etc. Es decir, envía más información de la imprescindible. Además, el listado resultante no es tan funcional como el que tendrías en el explorador de ficheros, por ejemplo. Para conseguir parte de esas funcionalidades hay que trabajar más y sobrecargar más las páginas con scripts y otras historias haciendo cada página y cada autor una interfaz diferente, lo cual lleva a la confusión en los usuarios.
Ahora, imagina que en la página en cuestión, en vez de tanta historia pudiera poner algo así:

Y con ese trocito va el navegador y me pone un control de listado nativo del sistema operativo en el que resida, con sus botones de página siguiente, anterior, etc y se encarga de todo.
El resultado es que mi aplicación es mucho más ligera, más rápida de desarrollar, más amigable para el usuario y con una probabilidad de errores infinitamente mayor. Y sin perder ninguna ventaja de lo que me aporta la web.
Yo creo que no es precisamente ciencia ficción hacer algo así, pero requiere que se haga de la forma más estandar posible, y a poder ser que lo "adoptara" el w3c o similar.
No olvidemos que el navegador en si mismo es un "fat client", lo que es "thin client" es la aplicación web que corre en el.

Narciso Cerezo | 22 de Agosto, 2005, 17:47 | (Contacto, Página)
Vaya, se ha "comido" mi pseudo-html, así que lo intentaré de nuevo sin los signos de "menor" y "mayor":
list source="http://loquesea.com/consulta.xml" definition="http://loquesea.com/definicion.xml" style="http://loquesea.com/style.xml" pageSize="20"

Daniel | 22 de Agosto, 2005, 21:42 | (Contacto, Página)
Por cierto, google ya tiene su sistema operativo... que es en relidad su propiedad intelectual mas importante http://blog.topix.net/archives/000016.html. Cuando pienso en eso junto con esto www.yubnub.org y esto http://www.xintesis.com/2005/08/por_fin_aparece.html se me ocurre que las cosas se podrian poner interesantes.

Joserra | 22 de Agosto, 2005, 23:32 | (Contacto, Página)
Narciso, pero si lo único que circula por la red, son los datos que se deben mostrar, y el cliente debe SABER cómo mostrarlos... no le sigo viendo mucha diferencia con el cliente/servidor. !Ojo! que no digo que eso sea malo. Quizás las redes actuales de Internet ya lo permitan, descargarse una pequeña aplicación antes de entrar en una "web" (ya no serían webs propiamente dichas) y de esa manera tener el cliente.
Por que la idea de crear algo estandar para las aplicaciones, lo veo un poco difícil, es la idea que está detrás de todos los generadores de aplicaciones, y al final, cuando quieres salir de algo estandar, necesitas saltartelos y programar lo que realmente quieres.

De todas maneras, de lo que estoy seguro es que seguiremos viendo la evolución de las aplicaciones (más que webs) sobre Internet. O eso espero! ;)

Narciso Cerezo | 22 de Agosto, 2005, 23:50 | (Contacto, Página)
Joserra, creo que no me he explicado bien. Si te fijas en el pedacito de pseudo-html, describe el origen de los datos (que probablemente sea un servicio web), la definición de los mismos (tipo, iconos, etc) y el estilo (color, tipo de letra, etc), además de otros parámetros (tamaño de página). Es un breve ejemplo según se me venía a la cabeza. Es decir, que el cliente no debe SABER cómo presentarlo, sino que de una forma estandarizada podemos decirle como hacerlo, pero brevemente, con separación clara de presentación y datos, con mayor potencia e integración con el sistema operativo.
No se trata de cargar aplicaciones, ya sean applets Java (que no presentan controles nativos y requieren instalar un JRE) o los dichosos ActiveX que son un agujero de seguridad impresionante. El cliente no tendría que instalar nada.
En cierto modo, se trata de un lenguaje descriptor de aplicaciones, en vez de hiper-texto, derivado de SGML o XML.
Ya hay iniciativas en este sentido como el XUL de Mozilla, pero todavía tienen que cuajar.
El problema para que podamos ver esto, es que cuando IE se convirtió en el estandar de facto y MS controló casi por completo el mercado de navegadores, se paró la investigación. Gracias a Firefox, que gran navegador, la investigación vuelve a surgir, pero todavía no ha hecho más que empezar y hace falta algo más que evolución, hace falta una revolución.
Aún así, seguro que lo vemos :)

anmar | 24 de Agosto, 2005, 19:53 | (Contacto, Página)
Lo que propones no requiere de ninguna tecnología nueva. XUL + web service o winfx/avalon + web service o ...

El código necesario para ejecutar cada funcionalidad en el cliente se baja sólo una vez del servidor. Evidentemente el código quieres que esté firmado en el caso de aplicaciones importantes, pero eso también es posible. La comunicación con el servidor para obtener datos o enviarlos se realiza mediante un modelo de eventos que se comunica con web services. En fin nada nuevo bajo el sol.

Lo que hace falta es que alguien le ponga nombre para que se popularice. A fin de cuentas AJAX no es nada más que ponerle nombre a algo que se llevaba haciendo bastante tiempo.

El problema no está en que no exista la tecnología necesaria, el problema es que la gente sigue estancada en modelos de programación caducos.

Narciso Cerezo | 24 de Agosto, 2005, 20:14 | (Contacto, Página)
Anmar,
Claro que no es nada nuevo bajo el sol, no son maravillas tecnológicas. La historia está precisamente en la integración y la uniformidad, en no tener que bajar ningún componente, ni que firmarlos ni nada por el estilo, y sobre todo, en que la interfaz para el usuario sea consistente y uniforme.
La gran ventaja de los sistemas de ventanas (window$, X-Windows, MacOS, etc) es precisamente que las aplicaciones que corren sobre ellos comparten una forma de uso que hace que el usuario necesite poco o ningún aprendizaje para cada aplicación. Todas las ventanas y controles son estándar y se manejan de la misma forma.
Eso es lo que no hay ahora en las aplicaciones web, cada cual lo hace como mejor le parece, y si, queda muy "cool" y muy bonito, pero pierde la homogeneidad y pierde mucho en usabilidad. Eso por no hablar del comportamiento diferente de un navegador a otro.
No hay que perder nunca de vista la usabilidad, ya que si una aplicación no se usa no sirve para nada.

anmar | 24 de Agosto, 2005, 20:31 | (Contacto, Página)
Con bajar no me refería a que lo tuviese que hacer el usuario, si no al proceso interno en si mismo.

El usuario lo único que hace es pinchar en un menú (por ejemplo), solo que en lugar de bajarse la pagina web correspondiente, el navegador obtiene la definición del interfaz (por ejemplo xul) y lo ejecuta. Esa definición debería venir firmada en el caso de aplicaciones de gestión, pero nuevamente no es nada que afecte al usuario.

Con esa definición se le presenta una ventana que no difiere en nada a una ventana de cualquier otro tipo de aplicación. Al pinchar en cualquier botón se generan eventos que se comunican con web services, que permiten evitar ese trasiego de html innecesario que describías y que existe en las aplicaciones web actuales. Con el resultado de la operación el cliente presenta al usuario el típico diálogo de confirmación (por ejemplo).

Para el usuario, no hay diferencia entre eso y haber pinchado en un botón en word: mismo aspecto, misma rapidez, etc.

Narciso Cerezo | 24 de Agosto, 2005, 22:57 | (Contacto, Página)
Anmar,
Tranquilo, ya entendía que no es que lo baje el usuario, es una descarga automática de un componente.
Lo cierto es que lo que comentas tiene que ver con la web y aplicaciones distribuidas, pero entiendo que no con navegadores. Si tienes algún enlace ilustrativo e interesante te lo agradecería para salir de dudas.
Por contra, lo que yo proponía sigue siendo el navegador, sin descargas de ninguna clase y sigue siendo una aplicación ligera.
La ventaja de las aplicaciones ligeras es sobre todo las actualizaciones. Aunque pienso en el usuario final, no puedo evitar pensar más en el que hace la aplicación, y las actualizaciones son una auténtica pesadilla. ¿Que ocurre en el esquema que describes si introduzco una modificación en una pantalla? ¿Debe bajarse de nuevo el componente y sustituir al anterior? ¿Y que ocurre si hay dependencias con otros componentes que dependen de el pero que no se han actualizado? ¿O si hay un error en la actualización?
Para mi, la cuestión no es tanto el hacer aplicaciones distribuidas que es lo que creo que planteas. Da igual que sea con web services, rmi, corba o cualquier otro sistema. La cuestión es hacer que los navegadores sea más potentes y capaces de ejecutar mejores aplicaciones, a la vez que simplificar la vida de los desarrolladores.
Aún así, me parece interesante lo que cuentas para según que sistemas.

anmar | 25 de Agosto, 2005, 9:20 | (Contacto, Página)
Pero a fin de cuentas cualquier aplicación web ya es una aplicación distribuida. La cuestión es que con xul tienes un navegador capaz de ejecutar esas mejores aplicaciones (desde el punto de vista del interfaz de usuario claro). Y al desarrollador le facilita mucho esa separación del interfaz de la lógica de la aplicación.

Ahora mismo FF ya es un cliente ligero :) Por ejemplo, instala chatzilla en FF y pon en la barra de direcciones chrome://chatzilla/content/ Ahora para poder hacer eso FF exige que se descargue e instale previamente la aplicación, pero eso no es nada más que una decisión de diseño de MoFo. Perfectamente el código xul podría ser ejecutado directamente al hacer click en el enlace de turno (evidentemente no se podría ejecutar en el mismo contexto de seguridad dentro del navegador que el código instalado)

El problema que veo a cualquier paso en la dirección que planteas es que aumentará la barrera de entrada para el desarrollo de aplicaciones. La mayor virtud (o la mayor pega, según se mire) de html y todos los añadidos posteriores mediante lenguajes de script, es que los conocimientos necesarios para hacer aplicaciones sencillas es reducido.

Por ejemplo xhtml+css o la programación basada en eventos hacen la vida mucho más fácil a los desarrolladores de aplicaciones, pero sin embargo su grado de penetración es realmente bajo. Por qué? En mi opinión es simplemente más difícil de entender para el creador típico de contenido/aplicaciones. Si ya era realmente complicado hacer entender a una buena parte de la gente la diferencia entre el código que se ejecuta en el servidor y el que se ejecuta en el navegador, explicar la ejecución asíncrona lo veo ciencia ficción. Cada nueva tecnología que surge en esa dirección tiene cada vez menos penetración que la anterior. Normal, es que hay que saber más para entenderla/usarla adecuadamente.

Narciso Cerezo | 25 de Agosto, 2005, 13:16 | (Contacto, Página)
Efectivamente, las aplicaciones web son distribuidas, pero la parte que ejecuta el cliente es tan ligera que se descarga cada vez y se interpreta cada vez (el html), por lo que no requiere mantenimiento alguno, todo está realmente en el servidor, donde las cosas pueden estar muy distribuidas entre muchas máquinas realaes.
Pero realmente no veo porque dices que la barrera de entrada es menor. Para mi, alguien que no puede hacer ese tipo de cosas es porque no lo necesita, quiero decir, que para hacer una web de presencia en Internet, pues coges el FP o DreamWeaver y no hace falta apenas saber nada. Ahora bien, para hacer aplicaciones, hacen falta más conocimientos. En cualquier caso, yo creo que este tipo de cosas podrían ser solventadas en gran medida por las herramientas de desarrollo: arrastro un "control de listado", doy propiedades y le indico donde están las cosas. A mi, personalmente no me gustan mucho, soy más de editar con un editor de texto inteligente, tipo IntellJ Idea.
De hecho, yo creo que el XHTML+CSS (o este tipo de extensiones) debería ser más sencillo de generar con una herramienta (FP, DW, etc) que el HTML de toda la vida.
Pero con todo esto de la barrera de entrada... yo me pregunto (y es tema para otro debate) ¿cuando se saca un nuevo aparato médico, digamos un scanner, alguien se pregunta si lo va a poder utilizar cualquiera? Realmente no lo creo, se asume que quien lo vaya a usar dispone de los conocimientos adecuados, que no va a ser el conserje el que se encargue de hacerlo. Y al médico, radiólogo o lo que sea, se le presumen los conocimientos y la capacidad de mantenerse al día y aprender.
Yo creo que esto es lo mismo, personalemente ya son más los lenguajes y plataformas que he olvidado que los que manejo y conozco, y no soy tan mayor.

anmar | 25 de Agosto, 2005, 21:09 | (Contacto, Página)
Al sustituir html por algo más 'avanzado' como xul, el comportamiento de descarga + interpretación/ejecución por parte del cliente no cambia. Lo que cambia es que desaparece la necesidad de que esa descarga se produzca cada vez que se ejecuta la 'página'. La necesidad de actualización del código de interfaz se resuelve fácilmente haciendo que cada módulo de código de cliente se identifique con su versión y sea la parte se servidor (un web service) quien exija la actualización de ese código antes de proceder con ninguna 'acción'. El código de cliente al ejecutarse obtendrá (o enviará según el caso) del web service (de modo asíncrono) todos los datos necesarios para 'rellenar' el interfaz de cliente.

En cuanto a la barrera de entrada, yo lo veo cada vez peor. Cada una de estas tecnologías va siendo cada vez más exigente en cuanto a lo que hay que saber para usarla bien. Por ejemplo en html bastaba con coger un editor como DW y empezar a meter tablas dentro de tablas y a tocar opciones que más o menos se parecían a las que se usan en procesadores de texto. Todo se reducía a crear tablas y añadir fotos y texto.

En xhtml+css ya nos encontramos con unas cuantas cosas añadidas (el modelo de caja, los diferentes modos de posicionamiento, definir una buena estructura de divs, ...). Todas las características que lo hacen potente, son las que ya no veo tan fáciles de entender para alguien que coge un editor por primera vez.

Demasiados desarrolladores de aplicaciones web (incluso algunas bastante complejas), carece en gran medida de los conocimientos básicos para entender lo que están haciendo. Muchos se limitan a usar DW para intentar 'cuadrar como sea' el aspecto y 'pegar y apañar' trozos de código (vbscript, php, ...) que van encontrando por ahí (sin tener muy claro por qué funciona). De ahí que se oigan cosas como: 'pero si xhtml+css no me aporta nada nuevo' o 'si asp.net es lo mismo que asp cambiando la extensión' y perlas de ese nivel. Ojala no fuese así, pero ...

Blog alojado en ZoomBlog.com