¿Qué es Pinguy OS?
Pinguy OS es básicamente es una versión remasterizada de Ubuntu que trabaja fuera de la caja sin ningún problema y, además, se ve y se siente tan condenadamente excelente.
Aquí unas capturas:
Download Pinguy OS
Fuente [INGLES]
Para tener mutt funcionando con gmail (en Español) pueden usar estas configuraciones. Primero instalamos
apt-get install mutt o yum install muttEditar el archivo ~/.muttrc (NOTA: si su gmail no está en español tendrá que usar los nombres de las carpetas imap en el idioma correspondiente).
#GUARDAR ESTE ARCHIVO CON CHMOD 700 !!!! #Identificación set from = "TUUSUARIO@gmail.com" set realname = "TU NOMBRE" set imap_user = "TUUSUARIO@gmail.com" set imap_pass = "TUCONTRASEÑA" #Carpetas / Labels set folder = "imaps://imap.gmail.com:993" set spoolfile = "+INBOX" set postponed ="+[Gmail]/Borradores" set trash = "imaps://imap.gmail.com/[Gmail]/Papelera" set imap_check_subscribed = yes set imap_list_subscribed = yes #Carpetas locales #Recordarse correr esto la primera vez: #mkdir .mutt #mkdir .mutt/cache set header_cache =~/.mutt/cache/headers set message_cachedir =~/.mutt/cache/bodies set certificate_file =~/.mutt/certificates #SMTP set smtp_url = "smtp://TUUSUARIO@smtp.gmail.com:587/" set smtp_pass = "TUCONTRASEÑA" #Keybinds (atajos del teclado, pisar la letra g #y luego cualquiera de las otras letras) bind editor noop macro index gi "=INBOX" "Bandeja de Entrada" macro index gt "=[Gmail]/Todos" "Ver todos los correos" macro index ge "=[Gmail]/Enviados" "Correos Enviados" macro index gb "=[Gmail]/Borradores" "Borradores" macro index gp "=[Gmail]/Papelera" "Papelera" #La tecla "y" me muestra todas las carpetas/etiquetas en el IMAP macro index,pager y ? "Listar Carpetas" #Otros set move = no #No pregunta mover los mensajes a mbox set imap_keepalive = 900 #Extras # Cabeceras ignore "Authentication-Results:" ignore "DomainKey-Signature:" ignore "DKIM-Signature:" hdr_order Date From To Cc ignore * unignore from: date subject to cc unignore x-mailing-list: posted-to: unignore x-mailer: # Caramelito visual set markers=no # don't put '+' at the beginning of wrapped lines set pager_index_lines= 5 # how large is the index window? set sort = 'threads' set sort_aux = 'last-date-received' # Editor set editor='vim + -c "set textwidth=72" -c "set wrap" -c "set nocp" -c "?^$"' # Alias para tener una libreta set alias_file= ~/.mutt/aliases set sort_alias= alias set reverse_alias=yes source $alias_fileLuego corremos estos comandos:
chmod 700 .muttrc mkdir .mutt mkdir .mutt/cache touch .mutt/aliasesLuego simplemente con correr el comando mutt tenemos un lector de correo para gmail sencillo:
muttSeguramente les pregunta si desean aceptar el certificado, seleccionen que sí, es el certificado ssl de gmail.
Para moverse se puede usar las flechas del teclado, para ver todas las etiquetas/carpetas del gmail presionen la tecla “y” y para regresar al Inbox tan solo presionen “g” seguido de “i”
Espero que lo disfruten.
Ya se tiene una agenda tentativa para el Encuentro con las Comunidades de Software Libre a desarrollarse el 16 de Diciembre en los espacios del Auditorio de la Torre Ministerial, ubicados en la Esquina El Chorro, Avenida Universidad, La Hoyada, Centro Cultural Simón Rodríguez. De igual forma adjunto la invitación al Encuentro por parte del MPPCTeI.
0. Introducción
En este artículo se explica como pasar datos que vienen en el HEADER de un mensaje SOAP hacia la clase que implementa el servicio con Axis2.
El problema es que se quieren enviar algunos datos en el encabezado SOAP, y esos datos podrían ser usados por la clase que implementa el servicio (en Axis2 esta clase se llama Service Class). Estos son los datos que se quieren enviar en el mensaje SOAP:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ws="http://www.example.org/ws/"> <soapenv:Header> <a:Channel xmlns:a="asdf">Canal</a:Channel> <a:Username xmlns:a="asdf">username</a:Username> <a:messageID xmlns:a="asdf">mesageid</a:messageID> </soapenv:Header> <soapenv:Body> <ws:CatalogLookup> <CategoryCode>123</CategoryCode> <SearchTerm></SearchTerm> <MaximunPrizePoints>54</MaximunPrizePoints> <Channel>Canal</Channel> <Status>Active</Status> </ws:CatalogLookup> </soapenv:Body> </soapenv:Envelope>Básicamente son: Channel, Username y messageID. Ahora, esos datos deben ser pasados a la clase que implementa el servicio. En nuestro caso son varios los servicios que hay que hacer que deben obtener este encabezado, entonces estamos usando Eclipse 3.5 con los plugins de desarrollo web, primero generamos el WSDL con la herramienta de Eclipse.
1. Crear el servicio usando Axis2 con Eclipse.
Este excelente artículo Creando un servicio web a partir de su interfaz WSDL por Javier Cámara (http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=WSDL2Java) tiene todas las instrucciones de como hacerlo.
2. Crear un cliente de pruebas.
Aquí hay un tutorial muy bueno Desarrollar un cliente webservice desde WSDL en Axis2 por Julio César Pérez Arques (http://jcesarperez.blogsome.com/2007/08/26/desarrollar-un-cliente-webservice-desde-wsdl-en-axis2/) que explica como crear el cliente. En nuestro caso solo nos interesan los clientes síncronos.
Luego de crear el cliente nos genera una clase Stub. Creamos una clase que contenga un método main() de Java y allí metemos nuestra prueba, incluyendo los encabezados:
package cliente; import java.rmi.RemoteException; import javax.xml.namespace.QName; import org.apache.axis2.client.ServiceClient; import cliente.WsStub.CatalogLookupResponse; import cliente.WsStub.ItemType; public class Prueba { public static void main(String[] args) throws RemoteException { // Se le indica el url donde se desplegó el servicio web WsStub ws = new WsStub("http://localhost:8080/PruebaWsdl4/services/ws?wsdl"); // aquí pone los encabezados. ServiceClient sc = ws._getServiceClient(); sc.addStringHeader(new QName("http://digitel.com.ve/", "Channel"), "mega"); sc.addStringHeader(new QName("http://digitel.com.ve/", "Username"), "camilo"); sc.addStringHeader(new QName("http://digitel.com.ve/", "messageID"), "msg23443"); // aquí pone unos valores en el cuerpo del mensaje (los parámetros) WsStub.CatalogLookup cl = new WsStub.CatalogLookup(); cl.setChannel("as"); cl.setStatus(WsStub.Status_type1.Active); // hace la llamada al WS CatalogLookupResponse r = ws.CatalogLookup(cl); // nuestro WS retorna un arreglo de objetos, pero obtenemos // el primero y lo mostramos ItemType i = r.localItem[0]; System.out.println(i.localChannel); System.out.println(i.localDisabled.getValue()); } }Observe que poner los encabezados en el cliente es muy fácil, no así en el servidor. Hay otras formas de agregar encabezados al cliente como puedes ver en el artículo: Working with Custom SOAP Headers por Deepal Jayasingha (http://wso2.org/library/3156)
3. Crear el handler de Axis2 que leerá los encabezados en el Servicio.
Hay que crear un handler de Axis2 para poder leer los encabezados del servicio y pasarlos a la clase que implementa el servicio. En nuestro caso estamos implementando los servicios con el Skeleton que genera Axis2 mediante el plugin de Eclipse. Entonces creamos una clase dentro del proyecto web del servicio así:
Observe que los valores se guardan en el MessageContext de Axis2. Luego la clase del servicio los tomará de allí.
4. Agregar el handler al axis2.xml para que sea invocado.
Para que el handler pueda correr hay que agregarlo al archivo WebContent/WEB-INF/conf/axis2.xml dentro del proyecto web. Busque la sección phaseOrder type=”InFlow” y agregue este trozo de XML:
Para que quede de la siguiente forma:
<phaseOrder type="InFlow"> <!-- System predefined phases --> <phase name="Transport"> <handler name="RequestURIBasedDispatcher" class="org.apache.axis2.dispatchers.RequestURIBasedDispatcher"> <order phase="Transport"/> </handler> <handler name="SOAPActionBasedDispatcher" class="org.apache.axis2.dispatchers.SOAPActionBasedDispatcher"> <order phase="Transport"/> </handler> </phase> <phase name="Addressing"> <handler name="AddressingBasedDispatcher" class="org.apache.axis2.dispatchers.AddressingBasedDispatcher"> <order phase="Addressing"/> </handler> </phase> <phase name="Security"/> <phase name="PreDispatch"/> <phase name="Dispatch" class="org.apache.axis2.engine.DispatchPhase"> <handler name="RequestURIBasedDispatcher" class="org.apache.axis2.dispatchers.RequestURIBasedDispatcher"/> <handler name="SOAPActionBasedDispatcher" class="org.apache.axis2.dispatchers.SOAPActionBasedDispatcher"/> <handler name="RequestURIOperationDispatcher" class="org.apache.axis2.dispatchers.RequestURIOperationDispatcher"/> <handler name="SOAPMessageBodyBasedDispatcher" class="org.apache.axis2.dispatchers.SOAPMessageBodyBasedDispatcher"/> <handler name="HTTPLocationBasedDispatcher" class="org.apache.axis2.dispatchers.HTTPLocationBasedDispatcher"/> <handler name="GenericProviderDispatcher" class="org.apache.axis2.jaxws.dispatchers.GenericProviderDispatcher"/> <handler name="MustUnderstandValidationDispatcher" class="org.apache.axis2.jaxws.dispatchers.MustUnderstandValidationDispatcher"/> </phase> <phase name="RMPhase"/> <!-- System predefined phases --> <!-- After Postdispatch phase module author or service author can add any phase he want --> <phase name="OperationInPhase"> <handler name="MustUnderstandChecker" class="org.apache.axis2.jaxws.dispatchers.MustUnderstandChecker"> <order phase="OperationInPhase"/> </handler> </phase> <phase name="soapmonitorPhase"/> <phase name="HeaderPhase"> <handler name="HeaderHandler" class="ve.com.ws.handler.HeaderHandler"> <order phase="HeaderPhase"/> </handler> </phase> </phaseOrder>Este artículo Handler and Phase in Apache Axis2 por Deepal Jayasinghe (http://www.packtpub.com/article/handler-and-phase-in-apache-axis) explica como es los de las fases (phase) y handlers de Axis2.
5. Modificar el esqueleto del servicio para que lea los encabezados.
Finalmente podemos leer los encabezados en el servicio. Edite la clase Skeleton que generó Eclipse para obtener los encabezados desde el MessageContext:
Este método para pasar los parámetros lo aprendí gracias a la respuesta de Nelson Minar a la pregunta How do I pass data from Handler to the service? que hizo Konstantinos Margaritis (http://www.mail-archive.com/axis-user@xml.apache.org/msg20035.html) en la lista axis-user http://ws.apache.org/axis/mail.html.
6. Conclusión
Es enredado leer los encabezados en Axis2 cuando usamos el esqueleto que genera la herramienta WSDL2Java o el Eclipse. Esto es así porque esa herramienta pretende ocultar las complicaciones de SOAP al programador que la utilice. Pero una vez configurado el handler podemos leero todos los encabezados y pasarlos a la clase que implementa el servicio.
En un evento especial, Google anunció anoche el lanzamiento de la tienda en línea de aplicaciones Chrome Web Store y del sistema operativo Chrome OS. Un proyecto ambicioso que pretende convertirse nada menos que en el ’sustituto de Windows’. ¿Podrá ser el primer Linux que rompa el monopolio de Windows en equipos de consumo?
Como estaba previsto, Google dio anoche el pistoletazo de salida para Chrome Web Store y Chrome OS. La primera, una tienda en línea al más puro estilo del Android Market para smartphones, que servirá como buscador, centralizador y suministrador de aplicaciones, juegos o herramientas, de pago y gratuitas.
Aplicaciones del propio Google, de grandes compañías (en la presentación se vieron juegos de Electronic Arts) y de terceros desarrolladores que como se anunció serán incentivados al máximo ya que Google cobraría únicamente un cinco por ciento de los ingresos de la aplicación cuando lo habitual en las plataformas de terminales móviles es cobrar el 30 por ciento. Chrome Web Store ya está disponible en Estados Unidos y se abrirá internacionalmente al resto de mercados a lo largo del próximo año.
Más importante que el anterior es el lanzamiento del Chrome OS, el sistema operativo con núcleo Linux y basado en Debian, con gestor de ventanas propio de Google, interfaz de usuario minimalista y totalmente orientado a la web ya que su concepción parte de una ‘extensión natural’ de su navegador web Chrome.
Concepción ‘en nube’ totalmente distinta a los sistemas operativos instalados y ejecutando aplicaciones en local que dominan actualmente el mercado, que ha sido diseñado en una época donde Internet es protagonista absoluto y con la web como plataforma.
También novedoso su lanzamiento, aún en fase de pruebas y bajo un programa piloto que contará con unos 100.000 testeadores (trabajadores de Google y usuarios cualificados, desarrolladores, centros educativos y empresas) a los que se les hará entrega no de una beta del sistema operativo sino de un portátil genérico de 12 pulgadas fabricado por Invectec con el sistema instalado y que será el hardware de referencia para las pruebas.
Los productos comerciales con Chrome OS llegarán durante el primer semestre de 2011 y de la mano de compañías como Acer y Samsung, los dos productores mencionados en el lanzamiento aunque es seguro que Google estará en negociaciones con una buena parte de la industria informática. En principio, Chrome OS iría enfocado a dispositivos portátiles (netbooks, mini-portátiles, Tablet…) aunque Google pretende extenderlo a cualquier equipo informático además de ser clave en la plataforma de televisión Google TV y en la más que probable red social Google Me.
Como se preguntan nuestros compañeros de Muy Computer en el anuncio del Chrome OS y ya hemos discutido por aquí en otras ocasiones ¿Podrá esta plataforma competir con Windows y Mac OS X en el mercado de ordenadores de consumo? ¿Será más bien un complemento a ambas en dispositivos específicos? ¿Podrá Chrome OS repetir en ordenadores el exitazo de su primo Android en smartphones? ¿Se impondrá la nube como el sistema operativo para ejecución de aplicaciones de uso mayoritario del futuro?
Fuente: MuyLinux
El presente artículo es una explicación basada en el ‘Stomp Protocol Specification, Version 1.0′ publicado por Codehaus en http://stomp.codehaus.org/Protocol.
1. El protocolo STOMPEl protocolo STOMP de colas de mensajes se utiliza para comunicación distribuida entre computadoras, principalmente en aplicaciones de informática. STOMP es el Protocolo de Mensajes Orientado a Texto y en Flujos (Streaming Text Oriented Messaging Protocol). Esto significa que los mensajes que se pueden crear y enviar por un lado, y recibir y procesar por el otro lado son mensajes de texto; puede ser cualquier documento de texto: plano, yaml, json, xml, etc. También significa que los mensajes se envían y reciben dentro de un flujo de datos, dicho de otra manera, mensajes van y mensajes vienen dentro de un mismo contexto de conexión.
Los servicios de colas de mensajes son utilizados desde hace mucho tiempo en aplicaciones dentro de bancos, empresas de telecomunicaciones y algunas otras industrias. Tienen mucha aplicación en la informática porque permiten una forma de computación distribuida con bajo acoplamiento, además es fácil de entender porque presenta un patrón de tipo productor-consumidor. Un caso fácil de entender sacado de morethanseven es cuando una web solicita información al cliente y cuando el cliente pulsa el botón de enviar la web le envía un correo electrónico, digamos con un resumen de su petición; si llegan muchos usuarios a enviar el formulario, el servidor se pondrá lento enviando correos, mientras que los usuarios irán notando que la página se vuelve lenta; esto ocurre porque el envío de correo toma un poco de tiempo y el servidor de web es quien está enviando cada correo (con la ayuda del servidor de correos).
Servidor de Colas
Ahora, si en vez de que el servidor web envíe el mensaje directamente al servidor de correo, lo coloca en una cola, esta cola a su vez está en un servidor aparte, y luego de dejar el mensaje en cola el servidor web muestra una respuesta al usuario liberandose para los demás usuarios que envíen el formulario. Esto haría que el servidor web no se ponga lento tan rápido. Pero ¿qué pasa con el mensaje? aún no se ha enviado por correo. Es cierto, el mensaje está en una cola en un servidor de colas, pero no se queda allí, porque la magia del servidor de colas es que este despacha el mensaje a un servicio que está procesando los mensajes de la cola, y ese servicio si va a enviar el correo: toma el mensaje de la cola y lo manda por correo; si llegan muchos mensajes, no importa, el servidor de colas de mensajes los va agregando al final de la cola y va despachando uno a uno según el proceso que los consume los pueda ir tomando y enviando sin saturar los recursos ni del servidor de correos y menos del servidor web.
Entonces el sistema es muy sencillo, un proceso escribe mensajes en el servidor, el servidor los mete en una cola y los va despachando hacia otro proceso que los va consumiendo según tenga disponibilidad de recursos.
Existen otros protocolos de mensajes como XMPP, SMTP o JMS para nombrar solo algunos y dejar por fuera mucho más. STOMP es un protocolo sencillo y ligero, por lo tanto está condenado al éxito y a ser usado en muchas aplicaciones que requieran sencillez y facilidad de uso. A partir de este punto se va a explicar el funcionamiento del protocolo STOMP basado en la propia especificación del protocolo.
2. El cliente se conecta con el servidor STOMP.Lo primero que debe hacer el cliente es abrir un socket al servidor. Es conveniente asumir que la conexión será con TCP ya que es lo más común y los servidores están hechos así. Para conectarse, un cliente debe enviar la siguiente trama:
CONNECT
login:usuario
passcode:clavesecreta
^@
El símbolo ^@ es un byte null (control-@ en ASCII). Se usa para definir el fin de mensaje. Toda trama inicia con un comando (en este caso CONNECT que significa conectar) en una línea, siguen los encabezados en forma ‘clave:valor’ cada uno en su propia línea (login y passcode en este ejemplo), se deja una línea en blanco y luego viene el cuerpo del mensaje, el cual termina con el byte ^@ (en este caso el cuerpo del mensaje está en blanco). El encabezado ‘login’ (entrar) se usa para enviar el usuario que se conecta, mientras que passcode (código de pase) se usa para enviar la clave secreta. Para separar las líneas se usa un caracter de nueva línea al final de cada línea.
Luego que el cliente envía la trama CONNECT el servidor responde con la siguiente trama:
CONNECTED
session:identificador de sesión
^@
CONNECTED significa conectado. El encabezado session es un identificador que puede ser cualquier texto con tal que sea distinto para cada conexión que se haga con el servidor (la especificación lo manda, pero no es usado para nada actualmente; en el futuro puede ser usado en otras tramas).
Ya con esto se establece una conexión al servidor y se pueden realizar varias acciones, cada una con su trama:
Entonces lo primero es conectarse, luego se pueden enviar o consumir muchos mensajes, dependiendo del lado donde esté el proceso (en el lado que pone mensajes o en el lado que los consume) y finalmente en algún momento se cierra la conexión. Esta es la parte de flujos del protocolo, como se puede ver todo ocurre dentro de un flujo de mensajes que van y vienen entre el servidor y los clientes que ponen mensajes y que consumen mensajes.
3. Comandos que pueden enviar los clientes. SEND.Significa enviar. Sirve para enviar o colocar mensajes hacia un destino en el servidor. Este lo usa el cliente que quiere poner un mensaje en una cola. Tiene un encabezado requerido: destination (destino) que indica donde se va a enviar el mensaje. El cuerpo de la trama SEND es el mensaje que se quiere enviar. Ejemplo:
SEND
destination:/cola/mensajes
Texto del mensaje puesto en la cola
^@
Esto envía el mensaje ‘Texto del mensaje puesto en la cola’ a la cola llamada ‘/cola/mensajes’. El nombre de la cola es totalmente arbitrario; en este ejemplo se usó la palabra ‘cola’ pero en el servidor no necesariamente es una cola, puede ser otra cosa que el servidor quiera implementar, no hay nada que obligue al servidor a usar una cola. Los nombres en ‘destination’ (destino) únicamente identifican un lugar en el servidor para poner los mensajes, cada nombre indica un lugar distinto, cada servidor puede implementar este mecanismo como quiera.
Las tramas SEND soportan un encabezado ‘transaction’ (transacción) que sirve para enviar el mensaje en el contexto de una transacción.
Se recomienda que las tramas SEND incluyan un encabezado ‘content-length’ (longitud del contenido) que es el número de bytes del cuerpo del mensaje. Esto sirve cuando el mensaje incluye caracteres de null (^@); si no se incluye un content-length el servidor tomará el mensaje hasta el primer null que encuentre e ignorará el resto del mensaje; por el contrario si tiene content-length el servidor leerá esa cantidad de bytes del mensaje, incluyendo los bytes que sean null (^@).
SUBSCRIBESignifica suscribir. Se usa para registrar que se quieren consumir mensajes de un destino (‘destination’) dentro del servidor; por ejemplo consumir mensajes de una cola. Al igual que la trama SEND, la trama SUBSCRIBE requiere un encabezado ‘destination’ (destino) para indicar la cola a la que se quiere suscribir. De esa forma, cualquier mensaje que se reciba en la cola (porque otro proceso puso el mensaje) será enviado desde el servidor al proceso cliente que se suscribió a la cola como una trama MESSAGE (mensaje). Se puede colocar un encabezado ‘ack’ (confirmar, acknowledge), pero es opcional y si no se coloca el valor es ‘auto’. Ejemplo:
SUBSCRIBE
destination:/cola/mensajes
ack:client
^@
En este ejemplo el encabezado ‘ack’ (confirmar) está en ‘client’ (cliente) lo que significa que el mensaje será considerado como enviado al proceso cliente cuando el proceso cliente envíe al servidor una trama ACK (confirmación). Los valores válidos para el encabezado ‘ack’ son ‘auto’ (automático, que es el que se asume por defecto si no se manda encabezado ‘ack’) y ‘client’ (cliente).
El cuerpo de las tramas SUBSCRIBE (suscribir) es ignorado completamente.
Se puede agregar un encabezado ‘id’ (identificador) que podrá ser usado luego en una trama UNSUBSCRIBE (desuscribir), de esa forma, si un proceso tiene varias suscripciones a un mismo ‘destination’ (destino), puede elegir a cual de-suscribirse porque le asignó distinto ‘id’ (identificador) a cada proceso. Si se indica un encabezado ‘id’ entonces el servidor deberá agregar a su vez un encabezado ‘subscription’ (suscripción) a las tramas MESSAGE (mensaje) que él envía al cliente suscrito, de forma que el cliente podrá saber exactamente a cual suscripción se refiere la trama MESSAGE (mensaje). Si el servidor soporta comodines (wildcards) y selectores (selectors) el ‘id’ puede servir a los clientes de ayuda para saber cual suscripción originó el mensaje. Los comodines y selectores se explican más abajo. El servidor podría soportar un encabezado ‘selector’ que puede contener un selector de tipo SQL 92 como se explica hacia el final del artículo.
UNSUBSCRIBESignifica de-suscribir. Esta trama se utiliza para remover una suscripción existente de forma que ya no se reciban más mensajes provenientes del destino (destination) al que previamente se suscribió. Requiere uno de estos dos encabezados: ‘destination’ (destino) o ‘id’ (identificador). Para usar el encabezado ‘id’ tuvo que haberse pasado también al momento de hacer la suscripción. Ejemplo:
UNSUBSCRIBE
destination:/cola/mensajes
^@
BEGINSignifica iniciar. Se usa para iniciar una transacción. Las transacciones en este protocolo solo aplican a envío de mensajes y confirmación de recepción de mensajes. Cualquier mensaje enviado o al que se le confirme su recepción será manejado atómicamente durante la transacción. Ejemplo:
BEGIN
transaction:identificador
^@
El encabezado ‘transaction’ (transacción) es requerido y se refiere a un identificador que deberá ser usado en las tramas SEND, COMMIT, ABORT y ACK para indicar que están asociadas a la transacción por el nombre dado en el identificador.
COMMITSignifica comprometer. Se usa para ejecutar definitivamente una transacción en curso, es decir, para indicar que la transacción terminó exitosamente y deben ejecutarse atómicamente todos comandos enviados desde el BEGIN. Ejemplo:
COMMIT
transaction:identificador
^@
El encabezado ‘transaction’ (transacción) es requerido y se refiere al identificador que se indicó al iniciar la transacción con la trama BEGIN.
ACKSignifica confirmar (acknowledge). Se utiliza para confirmar la recepción y consumo de un mensaje de parte del cliente, cuando el tipo de confirmación es ‘client’ (cliente). Cuando un cliente envía una trama SUBSCRIBE (suscribir) con un encabezado ‘ack’ (confirmación, acknowledge) con valor ‘client’ (cliente) entonces para que el servidor considere que el cliente ha consumido el mensaje, el cliente debe enviar una trama ACK de confirmación.
ACK tiene el encabezado ‘message-id’ (identificador del mensaje) como requerido, y el identificador debe coincidir con el que envía el servidor en la trama MESSAGE (mensaje) correspondiente para ser confirmada. Adicionalmente un encabezado ‘transaction’ (transacción) puede ser usado para indicar que la trama está dentro de una transacción. Ejemplo:
ACK
message-id:identificador
transaction:numero de transacción
^@
El encabezado ‘transaction’ es opcional.
ABORTSignifica Abortar. Se usa para indicar que se debe abortar o rechazar una transacción en curso. Es decir, que ningún mensaje dentro de la transacción debe ser enviado. Ejemplo:
ABORT
transaction:numero de transacción
^@
El encabezado ‘transaction’ (transacción) es requerido para identificar la transacción.
DISCONNECTSignifica desconectar. Se usa para desconectarse limpiamente del servidor. Es adecuado hacer una desconexión antes de cerrar el socket TCP. Ejemplo:
DISCONNECT
^@
4. Encabezados estándar.Algunos encabezados pueden ser usados en la mayoría de las tramas y tienen un significado especial.
receiptSignifica recibo. Cualquier trama que envíe el cliente menos CONNECT puede hacer uso del encabezado ‘receipt’ con un valor arbitrario. Esto hará que el servidor confirme la recepción de la trama enviando al cliente una trama RECEIPT que contendrá el valor del este encabezado en el encabezado ‘receipt-id’ de la trama RECEIPT. Ejemplo:
SEND
destination:/cola/mensajes
receipt:mens876
Mensaje con confirmación de recibo.
^@
El servidor enviará también tramas al cliente, adicional a la trama CONNECTED (conectado) que envía al momento de la conexión puede enviar también:
Significa mensaje. Estas tramas se usan para enviar los mensajes de las suscripciones a los clientes suscritos. Las tramas MESSAGE contienen un encabezado ‘destination’ (destino) indicando la cola destino que recibió el mensaje. También contendrá un encabezado ‘message-id’ (identificador del mensaje) con un identificador único. El cuerpo de la trama contiene el mensaje. Ejemplo:
MESSAGE
destination:/cola/de/ejemplo
message-id:identidad9001
Este es el mensaje^@
Se recomienda que las tramas MESSAGE incluyan un encabezado ‘content-lenght’ (longitud del contenido) con una cuenta de los bytes del cuerpo de la trama. Si viene el encabezado ‘content-length’ entonces se leerán esa cantidad de bytes. Esto permite tener caracteres null en el cuerpo del mensaje.
RECEIPTSignifica recibo. El servidor envía tramas de recepción cuando el cliente ha especificado un encabezado ‘receipt’ en algún comando. La trama RECEIPT contiene un encabezado ‘receipt-id’ que contiene el mismo que vino en el encabezado ‘receipt’ que envió el cliente. Ejemplo:
RECEIPT
receipt-id:mens876
^@
El cuerpo del mensaje debe estar vacío.
ERROREl servidor podría enviar tramas ERROR si algo va mal. Las tramas de error contendrán un encabezado ‘message’ (mensaje) con una breve descripción del error, el cuerpo podrá contener todos los detalles del error o venir vacío. Ejemplo:
ERROR
message:trama no reconocida
El mensaje:
-----------
COLA
destination:colademensajes
Datos del mensaje
-----------
no contiene un comando válido del protocolo STOMP.
^@
Se recomienda que las tramas ERROR incluyan un encabezado ‘content-lenght’ (longitud del contenido) con una cuenta de los bytes del cuerpo de la trama. Si viene el encabezado ‘content-length’ entonces se leerán esa cantidad de bytes. Esto permite tener caracteres null en el cuerpo del error.
6. Comodines (wildcards)Esta sección es una explicación basada en la página de Apache ActiveMQ sobre Wildcards de The Apache Software Foundation ubicada en http://activemq.apache.org/wildcards.html.
El soporte de comodines sirve para suscribirse en un solo comando SUBSCRIBE a varias colas. Un ejemplo clásico de esto es cuando existen varias colas cada una de las cuales lleva el control de los cambios de precios de una acción en particular, entonces se tendrían varias colas como por ejemplo:
Si se quiere que una sola suscripción consuma todas las colas de acciones clase A (CRM.A y MVZ.A) entonces puede suscribirse con el siguiente comodín:
SUBSCRIBE
destination:bolsavalores/rentavariable/*.A
^@
Se observa que el * significa que puede haber cualquier texto en ese lugar.
En otro ejemplo un proceso quiere suscribirse para consumir todas las colas de renta variable, puede hacer así:
SUBSCRIBE
destination:bolsavalores/rentavariable/>
^@
En este caso el símbolo > (mayor que) significa que puede haber cualquier texto de allí en adelante.
Entonces:
Esta sección es una explicación basada en la página de Apache ActiveMQ sobre Selectors de The Apache Software Foundation ubicada en http://activemq.apache.org/selectors.html.
Los selectores se utilizan para recibir únicamente algunos mensajes de una suscripción y no todos. Normalmente se reciben todos los mensajes que llegan a una cola a la que se está suscrito, pero si se usan selectores se podrían filtrar algunos mensajes.
Los selectores utilizan sintaxis de SQL 92 y solo se pueden usar claves del encabezado, por ejemplo:
SUBSCRIBE
destination:/mi/cola/con/muchosMensajes
selector:id = 'cola080' and ack='client'
^@
Los selectores no pueden usarse con el cuerpo del mensaje, solo con los encabezados.
8. Algunos enlacesCopyright 2010. Camilo Torres.
Este obra está bajo una licencia Creative Commons Reconocimiento 3.0 Unported.
Este es básicamente el post de @guerrerocarlos, lo único que le modifiqué fue el link de descarga de el ROM[3] ya que publicaron una actualización en donde corrigen ciertos errores con la app de la cámara y con la galería. Ya lo lo instalé y de verdad que funciona excelente, de verdad incrementó el rendimiento mi equipo ademas de agregar un montón de características y funcionalidades extras. Me da la impresión de que le dura mas la batería también.
Al final agrego un vídeo de demostración, quizá noten que al principio trabaja un poco lento por unos segundos, pero es por que está terminando de cargar, luego agarra mínimo:
Huawei no lanza aún una actualización oficial para este equipo y tampoco parece que vaya a hacerlo, a pesar de las muchas mejoras que trae la versión 2.2 de modo que no quedamos que recurrir a vías alternativas para actualizar nuestro U8220 a lo último en Android, nosotros podemos hacerlo de todas maneras:
La gente de cyanogenmod se especializa en generar firmware especialmente diseñado para sacarle el maximo provecho (desempeño y estabilidad) a tu equipo, basados el en proyecto Open Source Android, siendo en la mayoria de los casos, mucho mejor que el propio firmware que trae el equipo de fabrica. Estas imagenes incluyen además sistemas sin limitaciones o ya “rooteados” de manera que puedes instalar aplicaciones que normalmente no puedes si usas el sistema original, como por ejemplo para hacer “tether” es decir convertir tu celular en un router para compartir internet.
Lamentablemente el U8220 o “Pulse”como se conoce internacinonalmente, aún no es mantenido oficialmente por cyanogenmod pero un miembro de la comunidad Modaco.com llamado “Tom G.” a hecho el mod para poder instalar Froyo en el U8220.
Los pasos para instalar Android 2.2 en tu Huawei U8220 (de Movilnet):
Descarga todos los siguientes archivos: [1]Recovery, [2]Time Machine, [3]Mod Froyo hecho por Tom G, [4]GoogleApps. Opcionalmente puedes descargar la [5]ROM original de Movilnet, en caso de que luego quieras devolver tu sistema a Android 2.1 (muy poco probable que quieras eso).
Aprovecho para copiarme la advertencia que traen estos proyectos:
A pesar de que estos proyectos te ayudan a sacar mayor provecho a tu Android, NO ME HAGO RESPONSABLE por equipos bloqueados, tarjetas SD muertas, ni por la guerra termonuclear ni por la crisis economica actual. Por favor investiga acerca de las características incluidas en estas ROM antes de flashearlas. USTED esta eligiendo hacer estas modificaciones y si me señalas a mi por dañar tu equipo, me reiré.
Descomprime el archivo [1] que descargaste.
1.- Apaga el U8220 y enciendelo de nuevo presionando la combinación de botones [Bajar Volumen + Colgar + Encender] hasta que veas la siguiente pantalla:
Modo comunicacion serial
2.- Conecta el celular al puerto USB de tu computadora y si estas en Linux: ejecuta el script ./install-recovery-linux.sh (con permisos de root). Si estas en Windows tienes que correr es el archivo install-Clockwork-windows.bat si estas en mac, ./install-recovery-mac.sh
2.1.- Espera unos segundos a que diga OK
3.- Reinicia el U8220 quitandole la batería unos 4 segundos y vuelvela a poner.
4.- Si se enciende automaticamente, espera y vuelvelo a apagar.
5.- Copia en la la raiz de la memoria SD de tu celular los archivos [3] y [4] y vuelve a insertarla en el U8220. (los .zip, no los descomprimas)
6.- Enciende U8220 presionando la combinación [Menu + Colgar + Encender]
7.- Espera a que salga la siguiente pantalla:
Clockwork funcionando
8.- Selecciona la opción install zip from sdcard
Seleccionar archivo .zip desde tarjeta SD
8.- Selecciona la opción choose zip from sdcard
9.- Selecciona instalar el archivo [3] existente en la SD y luego acepta descomprimirlo, presionando la tecla verde. PRIMERO DEBE SER INSTALADO CM6.1-RC0-Pulse-beta-0.30.zip luego si gapps… pendientes de eso.
Seleccion de .zip
10.- Selecciona instalar el archivo [4] existente en la SD y luego acepta descomprimirlo, presionando la tecla verde.
11.- Selecciona la opción wipe data/factory reset
Limpiar todo el sistema y restablecer como de fabrica
12.- Confirma que estas seguro (YES).
Selecciona donde dice YES, el monton de NO son para asegurarse
13.- Selecciona la opción reboot system now
14.- Preparate para disfrutar de Froyo en tu U8220 despues del arranque 
Nota: los archivos [2] y [5] son para:
[2]: habilitar el equipo para instalar cualquier nueva ROM.
[5]: ROM original 2.1 para Huawei U8220 (Venezuela)
Ninguno de los dos se utiliza en este manual.
Información del Sistema U8220 con Android 2.2
El primero es el vídeo de Carlos y el segundo es el que agregué yo.
POR FAVOR QUIENES SIGAN ESTAS INSTRUCCIONES TOMAR FOTOS Y/O VIDEOS PARA COMPLEMENTAR AUN MAS ESTE MANUAL. GRACIAS.
Fuentes: Blog de Carlos Guerrero ModacoCito correo enviado por José Soto del MCTI:
Un Cordial saludo estimados compatriotas, lo presente es para informarles, que la jornada de encuentro con las comunidades de software libre, previstas para el 07/12/2010 en los espacios del Comedor en el edificio anexo o Centro Cultural Simón Rodriguez del Ministeriodel Poder Popular para Ciencia, Tecnologias e Industrias,fue pospuesta para el día 16 de diciembre a las 8:30 AM hasta 12:30 M todo esto débido a situación climatologica del país (Lluvias), que han ocasionado graves daños en algunas zonas y por ende esto ocasionaria, que algunos de nuestros invitados se imposibilite para venir a este encuentro.
Atentamente
Jose Soto
Así que quedan todos cordialmente invitados a participar en el encuentro el día 16/12/2.010.
Hace ya algún tiempo escribí sobre el uso de libpam-ccreds y libnss-db para conseguir la implementación de un servicio de caché de credenciales. Sin embargo, hace casi un año revisité el producto Likewise Open, en un proyecto grande de autenticación de Linux contra un Active Directory de Microsoft, o contra un dominio Windows desarrollado con Samba.
En realidad Likewise Open elimina la incertidumbre de un setup artesanal de caché de credenciales, siempre y cuando el equipo se esté loggeando contra un dominio Windows.
Si usted tiene la necesidad de integrar una distribución de Linux moderna (una versión reciente de Debian, Ubuntu, Fedora, por ejemplo) con un dominio Windows servidor por un Active Directory o por Samba, mi recomendación es que use Likewise Open. Likewise es libre, abierto y gratuito, y viene en los repositorios de muchas distribuciones, o se baja de la página Web de Likewise.
Tiene dos versiones (paquetes), likewise-open-gui y likewise-open; el primero instala el segundo y ofrece una interfaz gráfica sencilla para unir el equipo al dominio. Solo se requiere el nombre del dominio, el nombre del equipo (se toma de hostname) y el usuario y la clave de un usuario que pueda agregar equipos al dominio.
Como siempre, la resolución del dominio se hace consultando al DNS provisto en la configuración de red (u otorgado por el DHCP) por ciertos registros SRV, para obtener la IP de uno de los controladores de dominio, y luego ciertas conexiones a algunos puertos del controlador de dominio. Por lo tanto es importante que, si va a probar este escenario en una máquina virtual, la conexión esté en modo puente con la red en la que se encuentra el controlador de dominio.
Una vez que el equipo se une al dominio, se crea la cuenta de máquina en el controlador de dominio, y al cerrar la sesión, ya pueden ingresar a Linux los usuarios del dominio, usando la sintaxis DOMINIO.AD\usuario o DOMINIO\usuario (formas largas y cortas) y la contraseña del dominio. Las políticas de inicio de sesión y contraseñas serán respetadas.
También se puede usar domainjoin-cli para unirse por CLI.
Obviamente, Likewise ya ofrece el servicio de caché de credenciales y de caché de usuarios y grupos (importa los grupos del dominio) y lo hace de forma transparente.
Por ello, en muchos casos yo recomendaría que si tienes un OpenLDAP y quieres hacer caché con pam-ccreds y nss-db, haz un “upgrade” de OpenLDAP a un dominio usando Samba y usa Likewise. Ahorra muchos dolores de cabeza.
En Likewise Open no hay soporte para GPOs. En ningún caso funcionarán las GPO que se hacen para Windows, pero en versiones pagadas de Likewise hay una función que añade nuevas GPO para GNOME y otras aplicaciones. No he probado estas funcionalidades.
(hacer clic en la imagen para ampliar)
Como todos sabemos ubuntu es la distro más popular del mercado, pero como indican la gente de MuyComputer.com: “podría alejarse –en el futuro- de los actuales ciclos de liberación de versiones semestral apostando por una actualización de software diaria. El ‘Centro de Software’ de Ubuntu implementado hace un año lideraría estos cambios. Desde Canonical indican que este centralizador de paquetes iría más lejos y más rápido de lo que en un principio se pensaba“
Mark Shuttleworth, tambien dice “Hoy tenemos un ciclo de liberación de seis meses…. En un mundo orientado a Internet tenemos que ser capaces de liberar algo todos los días…
“Esta es un área donde vamos a poner un montón de trabajo en los próximos cinco años. Los pequeños pasos que estamos dando hoy con el Centro de Software irán más lejos de lo que algunas personas podrían haber imaginado.
Ahora, en el blog de Novatillasku.com esta el siguiente post Canonical desmiente que Ubuntu adopte el Rolling Release,en el cual habla de que Rick Spencer, Director de Ingeniería de Canonical, ha desmentido que Ubuntu vaya a convertirse en Rolling Relesase, como hacen otras distribuciones.
“Ubuntu is not changing to a rolling release. We are confident that our customers, partners, and the FLOSS ecosystem are well served by our current release cadence. What the article was probably referring to was the possibility of making it easier for developers to use cutting edge versions of certain software packages on Ubuntu.This is a wide-ranging project that we will continue to pursue through our normal planning processes.”
En palabrasdel propio Rick Spencer.
Si clasificáramos ciertas épocas o períodos del Open Source en capítulos, ciertamente estaríamos en el comienzo de uno nuevo, uno que tiene como prefacio los negativos pasos de Oracle respecto a la filosofía Open Source, el desarrollo y próximo lanzamiento de GNOME 3 y los radicales anuncios hechos en la UDS.
Hablamos de un eventual reemplazo para el legendario X.org, salir de la rama 2.X de GNOME, la aparición de un fork de Open Office pero con apoyo ”popular” (Libre Office) y ver el nacimiento de lo que se perfila como un nuevo gran escritorio, como lo podría ser Unity de Ubuntu.
Cambios que se reflejarán fuertemente en el usuario final, una vez que estén listos y que apuntan especialmente a mejorar la experiencia de usuario. Por supuesto, falta tiempo para que todo esto ocurra y nada es 100% seguro, pero no está de más mirar de vez en cuando hacia al horizonte y especular un tanto con el futuro que de todas maneras va ser muy movido.
¿Que es lo que veremos en este nuevo capítulo?Bueno, en primer lugar tenemos a un GNOME que evoluciona, que sale de su aparentemente eterna rama 2.x para aventurarse con un desarrollo que es tan revolucionario como controvertido: GNOME Shell, en adelante, ésta sera la nueva cara de GNOME. Obviamente esta tercera entrega es mucho más que eso e incluye una multitud de componentes renovados y listos para establecer lo que será una nueva generación de este entorno.
Sin embargo los pasos que emprendió este desarrollo provocó algunas decisiones bastante radicales y opuestas, como la de Ubuntu de establecer un nuevo entorno llamado Unity, o la de Linux Mint de mantener el escritorio tradicional , si bien estos serán interesantes caminos que veremos a futuro, también significa que otra distro deberá llevar el estandarte de GNOME y por tanto, podríamos tener a otro importante actor más en este capítulo.
Una suerte muy distinta correrá KDE4, quien intercambiará papeles con el GNOME de hace algunos años mientras él recién crecía, ahora el escritorio “experimental” y ampliamente criticado se convertirá en el ”experimentado”, pero eso sí, contará con la enorme ventaja de haber avanzado una brutalidad en este corto tiempo, KDE definitivamente ha dejado la vara tremendamente alta para GNOME.
También podremos ver el aventurado camino que esta emprendiendo Ubuntu con su nueva interfaz, basada en Unity y Compiz, y apuntando además a sostenerse en Wayland, algo que definitivamente puede ser una gran innovación en interfaces en Linux, pero que no deja de ser tremendamente complicado de sostener, refiriéndome a mantener la estabilidad del sistema mientras se desarrolla sobre la marcha.
Respecto a lo anterior, ahora que Wayland es sacado a colación por Canonical, parece ser que todos los ojos empiezan a centrarse en él (dejando de lado un eventual X12), de hecho hasta Fedora ha expresado su interés en incluir este desarrollo, algo que podría dar el empujón definitivo a este tecnología y es que como mencionábamos hace un par de semanas, gran parte del trabajo ya está hecho en el kernel para poder ver a Wayland en acción.
Por otro lado, las diversas acciones de Oracle llevaron a la comunidad Open Source a intentar asegurar el futuro de la ofimática libre a través de la Open Document Foundation y su nueva suite de oficina llamada Libre Office, un fork de Open Office que ya ha absorbido a gran parte de su fuerza de desarrollo, además de que a contado desde el principio con el respaldo de grandes de la industria. Creo que habrá que acostumbrarse a este nuevo nombre de la ofimática abierta.
Por último, no podían faltar los nuevos personajes, Mageia y MeeGO, proyectos que se vienen gestando desde hace un tiempo y que esperamos, hagan su pronta y necesaria aparición, y digo necesaria por que buena parte del público espera ver el verdadero espíritu de Mandriva nuevamente en acción y también se necesita la aparición de MeeGO, simplemente porque están haciendo esperar demasiado a un mercado que tiene hambre y sed de innovación y versatilidad.
Agreguemos a este cóctel la nueva versión de GIMP, de Blender, un poco más de Open Shot y el potencial desarrollo de Lightworks, así como algunas mejoras que podrían hacerse bajo el capó como la implementación de Btrfs y systemd, y tenemos una mezcla a la que llamar “interesante” es poco.
De todos estos temas hemos hablado en muylinux, sin embargo quería detenerme un momento ordenarlos y condensarlos ya que conforman un gran panorama a futuro justamente a raíz de las radicales decisiones que se han tomado en este último tiempo y que han generado un punto de inflexión en el transcurso “normal” de los acontecimientos.
Espero no ser culpable de recurrentes casos de “versionitis”, pero todo esto se vuelve muy interesante y es que muchas veces las circunstancias más difíciles, pueden sacar lo mejor de nosotros o como se dice: “lo que no te mata, te fortalece” y esto al parecer, es aplicable a varias de estos proyectos de código abierto que serán protagonistas de un nuevo capítulo en la apasionante historia del mundo Open Source.
Fuente: Muylinux
SipDroyd es una aplicación de Telefonía IP que utiliza protocolo SIP. Está publicado bajo licencia GPLv3.
Estuve haciendo unas pruebas caseras para ver su comportamiento con Asterisk y funciona perfectamente, algunas de sus características funcionales:
Algunos Screenshots:
Características Tecnicas
Hardware
* Form Factor: Smartphone
* Processor: 528MHz (Qualcomm MSM7200A)
* ROM: 256MB (Flash EEPROM)
* RAM: 192MB (SDRAM)
* Display: 3.5″ Capacitive Touchscreen (320×480)
* Camera: 3.1 MP Auto-Focus (2592×1944)
* Additional Features: GPS, Compass, Accelerometer
* Expansion Slot: microSD, microSDHC
* Audio: 2.5mm Headphone Socket (Converter Included)
* Weight: 135g (with battery)
* Size: 62.5mm x 116mm x 13.5mm
* Battery: Li-Ion 1500mAh
Conectividad
* GSM: 850/900/1800/1900
* GPRS: Class 10 (4+1/3+2 slots), 32 – 48 kbps
* EDGE: Class 10, 236.8 kbps
* 3G: HSDPA (900/2100), 7.2 Mbps; HSUPA, 2 Mbps
* Bluetooth 2.0 (EDR, A2DP)
* WiFi 802.11b/g
* USB (Standard MicroUSB Connector)
Software
* Platform: Android
* Provider: Google
* Version: 2.1
* Proveedor: Movilnet
Precio: 1300 Bs
Aquí un link bueno de algunos datos y Configuraciones
El amigo Nelson Delgado, aka Nejode publico la siguiente noticia en Ubuntu-ve:
Del 16 al 19 de Noviembre se estará celebrando en la Universidad Politécnica Territorial del Estado Aragua “Federico Brito Figueroa” (antes Tecnológico de La Victoria) la Primera Jornada de Investigación, Extensión y Postgrado. El Grupo de Usuarios Linux (LUG) de esa institución (Ubunterizados), por medio del amigo Joel José Sanchez, ha invitado a la comunidad de Ubuntu-ve a participar junto con ellos en el Stand del LUG en el evento, que estará coordinando junto a la profesora Yamileth Vivas. Agradecemos a Joel esta nueva oportunidad para ayudar a difundir el Software Libre y Ubuntu en las instituciones educativas del País. Saludos también a los miembros del LUG: Carlos Morales, Sydney Fernandez, Maly Rivas, Jesus Tovar, Cesar Tenias, entre otros…
Hoy tuve la oportunidad de dar mi primer taller de APT en Ecuador, en la Escuela Politécnica del Ejército en Latacunga, en el marco del Encuentro Ecuatoriano de Software Libre.
La presentación está disponible en mi sitio de Scribd, y el video estará disponible en los próximos días en mis videos de archive.org.
Y continuando con los desktop mensuales aquí me voy con uno de Combat Arms EU la verdad aun no tengo claro de que trata el juego pero que demonios… Se ve muy interesante 
Aquí el wallpaper
.
O/s: Ubuntu 10.10 con el thema: Ambiance, el iconset es: -FFW Fast Forward tambien uso como dock: Docky el wallpaper es: Skynet Coorp.
Wallpaper realizado por: Cristina Astaltar Berety
Comparte y disfruta:
