Aquí tenemos otro articulito traducido por mí. Se trata de un tutorial de Chris Neeman destinado al diseño de un framework en PHP para crear una Intranet. El original, siempre mucho más fiable, lo podéis encontrar en DevShed.
Diseño de un marco de trabajo para una Intranet
Este artículo es la segunda parte de una serie sobre frameworks para aplicaciones para intranets. Ahora que sabemos todo sobre un marco de trabajo para aplicaciones y como funciona en un entorno intranet, vamos a ver la estructura general y el diseño de la intranet y de las aplicaciones. Sigue leyendo para ver como se va a hacer todo esto.
Primero vamos a crear una compañía ficticia que tiene algún tipo de base para las aplicaciones de intranet que vamos a crear. Después vamos a echar un vistazo al sistema de ficheros de la intranet. Y finalmente vamos a discutir el CSS y las plantillas que dará a las aplicaciones una apariencia similar.
No, no es broma, claro que no lo digo yo. El código fuente de este blog, tranquilos, se puede mirar y remirar.
Esto lo dice una firma de abogados, con intereses en la protección del copyright. En concreto, argumentan que como tienen los derechos de sus programas y sus códigos fuente, consideran también que tienen el copyright sobre el fuente HTML de su página web que puede mostrarte cualquier navegador. Por lo tanto, dicen que es ilegal ver su código HTML sin su permiso.
Para mear y no echar gota, podéis ver en detalle la noticia a partir de SlashDot.
Si os habéis leído la saga de Ilión, de Dan Simmons, veréis que en la historia aparece varias veces la mención a un acontecimiento histórico llamado “Rubicón“. Bueno, es un acontecimiento histórico dentro de una historia pasada en un futuro más o menos lejano, luego para nosotros sería un acontecimiento por pasar aun. Bueno, la cuestión es que el Rubicón es una especie de catástrofe cibernética, royo un supervirus. No lo puedo detallar más porque es algo que aparece en la historia como un dato de cultura general evidente y se menciona varias veces de pasada.
Bueno, todo este rollo es a modo de introducción a una noticia que me he encontrado por CNet News. Resulta que existe un proyecto llamado Rubicon, pero parece que no nos va a joder los ordenadores a todos y menos que vayamos a volver a la edad de piedra. Por lo que he visto en la noticia, el Proyecto Rubicon es una plataforma de anuncios que recoge en un solo panel de gestión mogollón de redes de anuncios (más de 300 redes) para poder ser optimizados todos y ganar más dinerito.
Pues sí, Google saca Google Sky, un add-on para el Google Earth mediante el cual podremos ver las estrellitas.
Con Sky podremos ver en imágenes más de un millón de estrellas y doscientos millones de galaxias, o eso dice la fuente de la noticia. Estos datos provienen del telescopio espacial Hubble, así como de animaciones de ciclos lunares.
El rollo está en usar el Google Earth normalmente y para mirar para el cielo, pues eso, mirar para el cielo y venga a mirar estrellas. Más datos para perder un rato.
Vía BBC News.
Resumen
Este documento contiene una propuesta para extender la API de Servlet como se define en la JSR 154 con asincronía para cumplir los objetivos de la JSR 315.
En este momento, esta propuesta es sólo una contribución de su autor (Greg Wilkins) y no una propuesta oficial de la JSR.
Introducción
Las características objetivo de JSR 315
JSR 315 nombra “Async and Comet Support” como una característica objetivo as a targeted feature, desacrita como:
Entrada no bloqueante
La habilidad de recibir datos de un cliente sin bloquear si los datos tardan en llegar.
Salida no bloqueante
La habilidad de enviar datos a un cliente sin bloquear si el cliente o la red es lenta.
Retrasar la gestión de la petición
El “estilo cometa” de una aplicación web AJAX puede requerir que la gestión de una petición sea retrasada hasta que ocurra un timeout o un evento.
Retrasar la gestión de una petición también es útil si hay que obtener un recurso remoto/lento antes de servir la petición o si el acceso a un recurso
específico necesita ser suprimido para prevenir demasiados accesos simultáneos.
Retrasar el cierre de una respuesta
El “estilo comet” de una aplicación web AJAX puede requerir que una respuesta se mantenga abierta para permitir que datos adicionales sean enviados cuando ocurran eventos asíncronos.
Notificaciones bloqueantes/no bloqueantes
La habilidad de notificar eventos bloqueantes o no bloqueantes. El concepto de canales - la habliddad de suscribirse a un canal y obtener eventos asíncronos de ese canal. Esto implica poder crear, suscribirse, desuscribirse y también aplicar algunas restricciones de seguridad sobre quién puede añadirse o quién no puede añadirse a un canal.
Read the rest of this entry »
Greg Wilkins ha dado una propuesta para los temitas de asincronía de JSR315 para el proceso de especificación de Servlet 3.0.
La propuesta se puede encontrar aquí, y en el blog de Greg hay una introducción a dicha propuesta. En la propuesta, el contenedor de servlet necesita nuevos poderes (gestionar más mime types), además de que hay más métodos de pedir servlets (requests) y de devolver objetos (responses), para gestionar suspensión y reanudación de peticiones (queeeee wapo!!!). El descriptor de despligue de aplicaciones web se debe modificar para indicar cómo convertir tipos, además de para indicar si un servlet es asíncrono o no.
Aunque la propuesta está fuertemente influenciada por Jetty Continuations, ésta intenta evitar algunos de los temas más polémicos de continuations.
A ver si tengo ganas y me la miro a fondo, y si tengo muuuchas más ganas al igual hago una traducción de estar por casa.
Vía TheServerSide.com.