kune-devel

Download

[email protected]

November 2007

1 participants
2 discussions

Para pensar: P2P
by Vicente J. Ruiz Jurado 21 Apr '08

21 Apr '08

Muy buenas: Desde hace tiempo llevo dándole vueltas a esta posible integración: http://kune.ourproject.org/wiki/index.php?title=P2P_-_Anonymous_file_sharing Creo que nos podríamos quitar problemas a la hora de permitir compartir ficheros grandes (como documentales, etc), y además proporcionaríamos una funcionalidad importante (compartir ficheros de forma anónima y protegidos de censura). La integración pienso que sería muy sencilla (lo explico un poco en el link). Quería enviarlo a la lista para que sonase. ¿Comentarios? Abrazotes, Vicente PD: Voy a intentar usar más la lista que las comunicaciones uno-a-uno están bien, pero no para todo...

2 3

Posibles soluciones para el tema de la internacionalización de kune
by Vicente J. Ruiz Jurado 10 Nov '07

10 Nov '07

Muy buenas: Escribo a la lista para darle un poco de vidilla y porque con las conversaciones 1-1, al final, no es tan enriquecedor. Un resumen de lo que he estado mirando. Se me ocurren tres opciones (aunque también se puede elegir una combinación de estas): 1) User constantes y mensajes (opción estándar de GWT) http://code.google.com/webtoolkit/documentation/com.google.gwt.doc.Develope… - Genera por cada locale código html en tiempo de compilación - Si se cambia el locale desde el GUI, hay que hacer toda un "refresh" completo en el cliente (carga diferentes .html/.xml) - En principio, si se cambia un .properties de un locale (solo), la compilación no se entera y no actualiza (por lo menos con gwt 1.4.60), pero estaría bien que solo compilara los ficheros que precisa. En definitiva requiere una compilación completa para cualquier modificación en las traducciones. - Usas métodos tipo miClase.AreYouSure(); Ventajas: se optimiza en tiempo de compilación para descartar cadenas no usadas en el código, detectar errores, etc. 2) Diccionario (segunda propuesta de GWT) http://code.google.com/webtoolkit/documentation/com.google.gwt.doc.Develope… - Generar un .js por cada locale (también se podría generar un solo js, con todos los diccionarios, pero cargarías todos los idiomas para cada cliente lo cual no tiene mucho sentido). - Todo en tiempo de ejecución - Propenso a fallos si falta alguna clave - Se manda todo incluso si no se usa - Adecuado para aplicaciones ya internacionalizadas - Al final, es similar a tener un hashMap, aunque más limitado. De hecho cuando cargas un diccionario, obtienes una especie de hashMap. 3) Generar servicio RPC para i18n propio (opción propia "casera", aunque ya hay gente opta por esta opción según leí en algún hilo). Si no nos gusta la opción 1) por los rollos de compilación y ya que la opción 2) en la práctica es bastante floja, creo que es más interesante generar una funcionalidad propia que básicamente recuperar del servidor un hashMap con todas las cadenas necesarias para un locale determinado. Tendríamos una llamada RPC inicial tipo: map = servicioI18n.getLocale("es"); y luego podríamos tener llamadas del tipo (a lo Globalize): t("Are you sure?") que buscaría esa cadena en el HashMap. También podríamos generar métodos tipo: public String AreYouSure() { return map.get("Are you sure?"); } si nos parece más elegante, pero no se si vale la pena. Siempre me ha gustado lo fácil que se internacionaliza con Globalize en rails. El hashMap lo podemos generar a partir de los datos de una tabla de bd. Si en un idioma determinado, no está traducido, se envía el del idioma por defecto. También se podría recuperar diferentes hashMaps por, por ejemplo, módulo, para no tenerlo todo en el servidor junto: chatMap = servicioI18n.getLocale("es", "ChatModule"); Inconvenientes de la opción 3): menos óptimo que la opción 1), un poco más de curro que la 1) ya que hay que generar ciertas clases y cierto modelo (aunque se puede fusilar de Globalize). Ventajas: más dinámico que la opción 1) ya que no requiere de compilaciones (con actualizar la fuente de datos basta), funcionalidad y prestaciones similares al diccionario 2), pero con la ventaja que podemos extender la clase para dar más funcionalidad sin estar atados al parseo de un simple fichero javascript. La misma funcionalidad se puede usar a nivel de servidor para los mensajes que se tendrán que generar para el cliente más allá de gwt (notificaciones por correo, parte pública estática, etc). Internacionalizar nuestro código actual sería sencillo (añadir el método Trans.t("Cadena") a las "Cadena" ya existentes). Más cómodo a la hora de programar (los .properties, es un coñazo). Entonces yo me decantaría por seguir con 1) en el cliente (aunque en el servidor se necesitaría algo adicional) o pasar directamente a usar la 2) que es la que me parece da más juego tanto en el cliente como en el servidor. ¿Se me escapa algo? Dani, ¿qué te parece? Seguro que sacas a relucir cosas que yo no veo. Abrazotes, -- Vicente J. Ruiz Jurado http://homes.ourproject.org/~vjrj/blog http://ourproject.org "Lo que ha sido creído por todos siempre y en todas partes tiene todas las probabilidades de ser falso." [Paul Valéry]

1 0