Artículo: Sincronización (Parte II)

Hemos visto en la primera parte la importancia de tener mecanismos que nos ayuden a sincronizar nuestros datos a lo largo de nuestros diferentes dispositivos. Ahora veremos los mecanismos que tenemos a nuestra disposición para tales efectos. Estos sistemas dependerán de los datos que deseemos sincronizar evidentemente, y evidentemente las limitaciones que tendremos vendran por parte de los servicios que estamos usando y del software cliente. Nos vamos a centrar en tres apartados, aunque se podrían sincronizar otro tipo de datos, y existen protocolos para ello, pero por ahora tan solo nos vamos a centrar en: Correo, Agenda y Calendario.



Correo:


Existen dos protocolos universalmente aceptados y estándares, bien conocidos por casi todos que serían POP e IMAP. Cada uno de ellos tiene sus pros y sus contras. Aunque parezca lo contrario, POP e IMAP sería una forma de sincronización de correo. a fin de cuentas podemos enviar correos, recibirlos... desde cualquier lugar gracias a estos protocolos. Parece curioso como aun siendo sistemas de sincronización (aunque quizás podríamos decir que POP no lo es) sus usuarios no saben en realidad que estan usando dichas tecnologías. No me gustan las tablas comparativas sobre que es mejor que no es mejor, que funciones tiene uno que el otro no... cada cual que saque sus propias conclusiones.



POP:

Si bien sabemos que POP no es un sistema de sincronización dado que tan solo se dedica a descagar el correo y ya está, podríamos decir que actua más o menso como un sistema de Polling de sincronización, aunque como digo no sería puramente un sistema como tal. Dependiendo de la gran cantidad de implementaciones de POP, el servidor podrá retener o no una copia del correo que se descarga. Lo más habitual es que las cuentas POP tan solo son útiles en la gran mayoría de los casos para entornos donde tan solo se desea leer el corro desde un sitio, dado que una vez el correo es descargado desde dicho dispositivo no se podrá recuperar desde otro.

Sobre POP al igual que IMAP se dedicó una entrada extensiva sobre ello, con lo que tampoco vamos a entrar en muchos detalles. Evidentemente, como todo protocolo o sistema usado, si deseamso hacer uso de esta tecnología, deberemos tener un proveedor de correo electrónico que permita conexiones POP y un cliente que permita realizar la conexión.

Pros: Rápido, facil de implementar.

Contras: No sería conveniente para leer el correo desde dos ubicaciones diferentes, tampoco es un sistema real de sincronización, los cambios efectuados tan solo se reflejan en local, no el servidor de correos mismo. En teoría no acepta tampoco carpetas de trabajo, dado que tan solo es un "descargador de correos". Al realizar accesos por Polling, hasta que no se realiza una petición, no sabremos si tenemos un correo nuevo

Consumo: Dado que es un método de Polling, significa que el consumo de ancho de banda o energético, será proporcional simplemente al número de veces que se realicen comprobaciones al servidor. No es un sistema optimizado, muchas de las peticiones devolverán cero correos, con lo que el ancho de banda y el consumo energético por ello será en vano.

Pese los pros/contras y consuno, no obstante para el usuario medio puede ser incluso más eficiente y mejor, dado que a lo mejor este usuario tan solo desea leer el correo una vez al día, siempre desde el mismo lugar, y por seguro que algún correo tendrá. Con lo que será consultar, descargar y se acabó, el consumo en este caso sería poco y los contras de POP no le implicarían nada. Se tendría acceso a los correos en el momento en el que se realizase la petición, si no hay petición no sabremos si hay correo.


IMAP:

IMAP es bastante más sofisticado. En este caso si podríamos hablar de una sincronización propiamente dicha, ya que cualquier dispositivo podrá acceder incluso a la vez a su servidor para recuperar cualquier correo. Cualquier cambio incluso q se realice de forma local se verá afectado en su servidor, con lo que podemos decir q la información se encuentra sincronizada en todo momento. Un mensaje leído desde IMAP permanecerá leído para todos los dispositivos, un mensaje eliminado estará eliminado en todos. Este sistema evidentemente será conveniente según las necesidades de cada uno. Si tan solo deseamos gestionar el correo en un PC y de manera rápida, simple, sin complicaciones y otros, a alguno podría interesarle usar POP en lugar de IMAP. Y al igual que POP, tendrá que ser un protocolo soportado por nuestro proveedor de correos y nuestro cliente.

Es importante destacar que tanto IMAP como POP realizan las peticiones al servidor de correo mediante Polling.

Pros: Sincroniza los correos, permite trabajar en local y sincronizar cuando esté online por ejemplo. Es una interfaz directa a nuestro servidor de correo. Permite la descarga selectiva de cabeceras o correos enteros, trabajar con carpetas y al estar sincronizadas, cualquier ubicación trabajará exactamente igual. Permite por tanto el acceso simultaneo a la cuenta, etc etc... Puede permitir tambien realizar búsquedas de correo sobre el servidor.

Contras: Es un sistema muchísimo más complejo que POP (POP es un sistema muy simple), y dado que todo se realiza de forma sincronizada, suele ser más lento, por ejemplo si guardamos una plantilla, la plantilla lo normal es que se guarda en el servidor, con el tiempo necesario para enviar dichos datos al servidor. Dado que es un sistema más complejo, normalmente los proveedores de correo no todos implementan IMAP. Al realizar accesos por Polling, hasta que no se realiza una petición, no sabremos si tenemos un correo nuevo

Consumo: En cuanto a consumo de ancho de banda suele consumir más que POP. Esto es pq cliente y servidor intercambian mayor información que simplemente los correos. Por otro lado tb el cliente suele enviar datos al servidor como por ejemplo que un mensaje ha sido eliminado, leído o guardado un borrador. Todo ello es ancho de banda, que implica proporcionalmente un incremente en cualquier consumo energético.

Este caso sería ideal para cualquier usuario con accesos desde diferentes lugares a sus cuentas, sacrificas algo de ancho de banda y mayor consumo para poder tener una sincronización real que de otro modo no tendrías. De nueco recordamos que una tecnología no es mejor o peor por sus recursos, sino para lo que se requiera si cumple con los objetivos.


IMAP IDLE:

Está aceptado como estandar. Es una extensión a IMAP que permite realizar un sistema de Push en vez de Polling. Consiste como hemos dicho anteriormente, en enviar una petición de espera latente, en la que nuestro cliente se mantendrá conectado por un tiempo "muy largo" a nuestro servidor. Cuando a nuestro servidor llega un correo entrante, este nos lo notifica por la conexión que está a la espera, con lo que la notificación debería de ser inmediata. Por lo demás su funcionamiento es igual a IMAP.

Su eficiencia no obstante depende normalmente de la implementación de cada servidor y sobre todo cada cliente. Posíblemente el parámetro más importante sería desde mi punto de vista cada cuanto tiempo máximo se debe de enviar una señal de KeepAlive. Como ya vimos en la primera parte de este manual, no podemos dejar eternamente una conexión establecida por diversos factores. Los dos más inmediatos son el TimeOut por parte del servidor y el TimeOut por parte de nuestro routers en caso de estar detrás de uno.

Esto que significa?. El TimeOut por parte del servidor es un tiempo establecido en ellos por el cual si no se detecta actividad de dicha conexión en ese tiempo, la conexión se cierra. Lo mismo sucede con el TimeOut de cualquier router que use NAT, la conexión se desecha de pasar un cierto tiempo. Esto quiere decir que el cliente que quiere mantenerse en modo idle debe de encargarse en mantener la conexión abierta. El como y cada cuanto tiempo, depende tan solo del cliente.

En teoría la norma es que antes de que sucedan los 30 minutos desde avisar del estado idle, se debe de dar por terminado el estado idle y rehacer la petición odle para otros 30 minutos. Esto es al margen de los correos, luego explico como funciona el sistema. Esto quiere decir que cada 30 minutos máximos nuestro cliente debería de hacer uso de nuevo del ancho de banda para realizar dichas peticiones. Lo normal llegado a este punto es usar comandos IMAP NOOP que significa "no hacer nada". Básicamente es como hacer un ACK o un pin al servidor destino para que este refresque la conexión, usando muy pocos bytes de información para ello. En teoría forzando muchos los tiempos se podría usar comandos NOOP cada 29 minutos. Cada 29 minutos existiría un consumo mínimo de ancho de banda y en consecuencia de transmisión de datos = consumo energético. El problema es que estos 29 minutos serían tan solo el salvaguarda de cara al servidor, no de cara a nusetro router. ¿Y como saber el TimeOut de este? Pues a menos que el router disponga de un sistema para saberlo, ya sea por web o telnet... tocará probar. Lo normal es que los router desechen conexiones pasados los 10-20 minutos. Mi Router por ejemplo se puede establecer el TimeOut, y ahora mismo lo tengo establecido en 60 minutos, con lo que en mi caso no sería problema.

Para terminar decir que los clientes IMAP IDLE suelen estar configurados de manera genérica para realizar NOOP cada 15 minutos aproximadamente. Ni que decir tiene que si la conexion se finaliza por tiempo de espera o por cualquier otra causa, estaríamos en el peor de los casos, y la conexion se debería de reestablecer de nuevo.

Os dejo unas capturas de pantalla de una sesión IMAP IDLE a la vieja usanza. La primera hace referencia exactamente a que sucede si no se ejecutan comandos tipo NOOP (u otros sistemas) para mantener la conexión abierta:




El primer paquete de la lista es la petición de idle. El servidor contesta con un ack y acto seguido responde con que se ha "activado" el modo idle y mi pc contesta con el ack correspondiente. Si os fijais en los tiempos, la conexión se queda ahí. Pasados 30 minutos el servidor al no detectar ninguna actividad en la conexión, inicia el handshake de fin de conexión.

¿Pero que sucede de cara a la sesión?


Los puntos rojos corresponden a lo que sería el cliente. El resto son las respuestas del servidor. Todo lo que precede al comando "IDLE", es simplemente la autentificación y pido solicitud de la bandeja de entrada, que dice que tengo 0 mensajes nuevos. Despues ejecuto "idle". 6 minutos después me envio un correo desde otra cuenta y que sucede? que segundos después aparece en pantalla la respuesta por parte del servidor a mi cliente avisando de que el correo número 10187 acaba de llegar. Minutos más tarde me vuelvo a enviar un correo, y de nuevo el aviso es recibido correctamente. Para acabar la sesión tecleo "done" para dar por finalizada la sesión idle y listo.

En este caso google soporta perfectamente IDLE. Para comprobar esto de todos modos tan solo sería necesario con teclear en la sesion IMAP anterior el comando ". capability". Se puede apreciar como todos mis comandos están antecedidos por un punto. En realidad puede ser cualquier cosa, es una etiqueta. Se usa debido a que se permiten sesiones múltiples por IMAP, y de esta forma se identifica mi sesión actual. Si el servidor me responde con un "." será un mensaje de respuesta a mi sesión específica, si responde con * son respuestas de modo global.

Un buen cliente compatible con IMAP IDLE debería por tanto mantenerse a la espera el máximo tiempo posible antes de enviar un ack/ping/NOOP...

La pregunta inmediata: ¿Es compatible la aplicación de nusetro dispositivo con IMAP IDLE? Por desgracia a Apple también se le olvidó implementar dicha extensión. Es posible que por el incremento en consumo, pero tampoco tendría esto mucho sentido dado que si permite realizar Polling incluso cada minuto!!, que seguro que el consumo sería muy muy superior. He visto comentarios de quienes afirman que si soporta IMAP IDLE, pero creerme, no lo hace.

Pros: Los correos llegan exactamente al momento, sin necesidad de requerir la petición al servidor. Esto puede evitar en caso de ser algo crítico, el uso intensivo del ancho de banda requerido que se necesitaría para realizar Polling cada 10 segundos a lo mejor.

Contras: Evidentemente aunque tenga un consumo bajo de ancho de banda, algo siempre existe, aunque se intenta minimizar lo máximo posible. No está considerado como un sistema Push puro, para ello se necesitaría acudir a sistemas de notificación SMS o similar.

Consumo: Inferior o superior a IMAP dependiendo de cada cuanto tiempo se tenga establecido el Polling. Si la idea es comprobar el correo cada 24 horas, IMAP IDLE es un consumo excesivo. Si deseamos ser notificados al instante de correo nuevo por el contrario, IMAP IDLE es la solución, ya que con IMAP tendríamos que realizar un Polling cada muy poco tiempo y ello llevaría a un enorme consumo.


P-IMAP

P-IMAP es una solución no estandarizada para realizar Push por IMAP. En realidad es un sistema similar a IMAP IDLE, aunque mas que similar deberíamos decir que IMAP IDLE forma parte añadida de P-IMAP. Pero por otro lado P-IMAP ofrece la posibilidad de que la notificación se realice por SMS o más automatizado por vía de WAP Push. Pero en esencia es lo mismo. Posiblemente no se llegue a estandarizar nunca dado las grandes diferencias entre compañias, el tipo de SMS, el tipo de WAP Push... depende de tecnologías que estas depende a su vez de las compañías. Aunque existe el planteamiento por algunos de que sea un estandar, dudo mucho que se convierta como tal, existiendo como ya existen IMAP IDLE. Es posible no obstante que en un futuro veamos IMAP4 actualizado para dar soporte a alguna tecnología estandarizada para tal efecto.

Al ser por tanto un sistema no estandar, su utilización por parte de servidores y clientes se ve reducido enórmemente, siendo ahora mismo usado básicamente por algunos programas y servidores, mientras que IMAP IDLE gana adeptos y cada vez más servidores lo permiten. Con lo que tampoco me gustaría darle más importancia a ello

Pros: Verdadero Push por medio de SMS o WAP Push.

Contras: En realidad las diferencias entre IMAP IDLE puede no ser justificable para la infrastructura requerida. Tener en cuenta que los servicios de notificación SMS o Push SMS suele ser un coste adicional por parte de nuestro operador, ISP o proveedor, con lo que para el usuario medio no sería una opción viable.

Consumo: Si se usa un sistema vía SMS por ejemplo, tan solo existe un consumo cuando se solicita la recepción del correo. En este caso nuestro dispositivo sabrá a ciencia exacta cuando ha llegado un correo y que puede descargarlo, iniciando una conexión desde cero nueva, sin neecsidad de mantener la conexión activa.


Existen sistemas de sincronización globales, pero esos los trataremos al final como protocolos de sincroniazción. Es cierto que IMAP pueda ser un protocolo de sincronización, pero me refiero a sistemas globales como pueda serlo GoogleSync, SyncML, ActiveSync, MobileMe...


-----------------------------------------
-----------------------------------------


Agenda y Calendarios:


Ahora nos toca abordar la agenda y los calendarios. Normalmente un recurso mucho más usado que el mismo correo electrónico, ya sea para buscar números de teléfonos, para buscar direcciones, notas... apuntar citas, cumpleaños, reuniones... hoy en día es casi imprescindible una buena agenda/calendario actualizadas. Y de eso vamos a tratar fundamentalmente, actualizada.

Al contrario que los correos, la agenda y el calendario tienen un problema añadido que no suponía para el correo, y este problema provoca la mayoría de los dolores de cabeza. Las incompatibilidades.

Está claro que un correo es un correo, un estandar definido perfectamente, ya sea un correo encriptado, un correo HTML, un correo en texto plano, los destinatarios que sean (ocultos, copias..). Está todo perfectamente definido, e incluso se puede expandir gracias a etiquetas concretas para ello. Pero para los calendarios y agendas electrónicas esto no es así. Sí, claro que existen estándares, pero luego cada cual hace un poco lo que quiere. Así por ejemplo en las agendas podemos ver algunas que puedes introducir todos los números de telefonos que desees, en cambio otros solo uno de casa y otro de trabajo, otros a lo mejor puedes configurar 3, pero no especificar de que tipo son... así con casi cualquier campo que podamos encontrar en uan agenda: Dirección, telefonos, correos, foto, notas, cumpleaños, empresa, nombre... algunas agendas tan solo computan un nombre en el que incluyen el apellido, otros tienen campos específicos para un solo apellido donde van los dos, otras dos apellidos... bueno creo que todos nos hacemos ya una idea de lo que implica esto. En caso de los calendarios es lo mismo, aunque tienen además el agrabante de los usos horarios, interpretar las mismas fechas... un caos.

Si esto es así, como diablos vamos a ser capaces de encajar (usando ya el protocolo que sea) una agenda que tiene mil campos en una agenda que tan solo contempla 10. Gracias a dios cada vez está todo más estandarizado y más o menos se tiende a una norma. Pero aun hoy por hoy existe cierta variedad de formatos diferentes, implementaciones de cada uno... aquí es cuando se agradece a aquellos que intentan en la medida de lo posible estandarizar las cosas.

Por ejemplo desde mi punto de vista, podemos tener a un lado SonyEriccson. Desde que han ido existiendo los estándares se han ido ciñedo a ellos: Agendas, calendarios, Bluetooth, notas, correo... Ventajas? es evidente, una mayor interoperatibidad. Al otro lado por ejemplo podemos ver Nokia. Una compañía que desde siempre ha intentado hacer las cosas a su modo (Como Apple). Hasta hace muy poco (algunos aun seguro que lo recordaran) si tenías Nokia, para poder pasar por BT un archivo ambos tenian que ser nokia, o el formato propietario para agenda/calendario, o para las notas usan simples arcihvos de texto... esto implica a la larga problemas. Tiene su lógica. Algunos desarrolladores (empresas) consideran que para el usuario final prima la versatilidad, la interoperabilidad... para otros prima el sello, el dar por culo y la exclusividad. ¿Que sucede con el tiempo? Que los estándares se afianzan, y las compañías que llevan años y años apollándolos sacan ventajas en implementaciones, velocidad, ideas... Así sucede por ejemplo q es tremendamente simple manejar un teléfono de SonyEriccson mediante comandos AT, o tener la seguridad casi del 100% que no vas a tener un solo problema de compatibilidad con nada.

Si volvemos a Apple, el problema es aun mayor. Apple en sus iPhone e iPod Touch usa formatos propios incluso en el sistema de guardado en disco. Esto puede hacer para muchos un infierno. No os podeis imaginar la de personas que me han preguntado como pueden exportar su agenda en sus teléfonos y meterla en un iPod o un iPhone y al revés. Gracias Apple por complicarnos la vida. ¿Que es lo que sucede al final? Que lo que podría ser algo muy simple si nativamente usa un estandar, a la hora de usar protocolos de sincronización estándares tienes que montar un jaleo increible para convertir los datos, adaptarlos... etc. Y muchos preguntarán... claro, pero al menos usan protocolos estándares, eso es bueno. Sí, es bueno, pero es que ha sido por obligación más que nada. Apple ya usaba (y usa, y lo veremos más adelante) como protocolos propietario de sincronización MobileMe. ¿Que sucede? Que además de ser de pago, no lo usa ni el tato, de ahí ahora a añadir la funcion de localización remota y demás... hay que intentar lo que sea. Si Apple no hubiese implementado protocolos como los que veremos ahora, el volumen de ventas para empresarios sería casi nulo, que ya de por si es muy bajo en comparación con BlackBerry.

Bueno, dejando todo ello a un lado... En el caso de la agenda y el calendario es diferente al del correo, puesto que para tener una agenda o un calendario no hace falta una conexión a inet la mayoría de las veces, no tienes que enviar nada, con lo que la sincronización o la conexión es completamente opcional.

Por eso mismo sería absurdo intentar listar cada uno de los formatos existentes, pues aunque existen algunos estándares como puedan serlo ldif, vcard, vcal... luego cada programador hace la implementación que le da la gana.


Directorios LDAP:

LDAP en realidad no se constituyó como agendas de teléfono o contactos. LDAP es un protocolo de acceso, sincronización y modificación a un directorio... una base de datos. En cierto modo son bases de datos estructuradas con un formato propio, con un acceso propio y otros, pero se puede asemejar a ello. Su uso es bastante abitual, por ejemplo en los servidores de DNS. Por como funcionan estos es muy común usar LDAP para las DNS. Pero al caso que nos atañe a nosotros, es para su uso como agenda.

Pero claro... ¿cual es entonces la idea de LDAP como agenda? Lo normal es usar una agenda siempre en local, pero pensar en una empresa. Una empresa con 1000 trabajodes por ejemplo, cada uno con su nombre apellidos y pongamos por ejemplo el correo electrónico de ellas. Sería tremendamente útil de cara a todos los trabajadores que todos los trabajadores tuviesen acceso a un directorio LDAP con dicha información, además a lo mejor de otro privado. De un solo golpe todos los trabajadores serían capaces de tener acceso a todos los correos de todos los compañeros.

Otro uso normal sería el que andamos explicando. La sincronización. Tener en algún servidor centralizado nuestra agenda LDIF (formato usado normalmente para LDAP), de modo que desde cualquier ubicación pudiésemos no solo tener acceso a ella, sino también modificarla.

Las posibilidades son muchísimas.



CalDav

Por un lado podríamos decir que es el homólogo a LDAP para calendarios, pero en realidad decir esto sería incorrecto. CalDav no es en sí una forma de almacenar datos, no es una base de datos, no es un sistema de directorios... es básicamente un protocolo de sincronización para calendarios usando el formato de calendarios iCalendar, y al margen de lo que pueda pensar ya la mayoría por la 'i' delante, no, no se trata de un formato desarrollado por Apple ni muchísimo menos, es un estandar en cuanto a calendarios se refiere, y CalDav es el protocolo de sincronización para ello. Esto nos permite por lo tanto poder acceder al igual que hacemos por LDAP a nuestra agenda, a nuestro calendario, estemos donde estemos, y teniendo la certeza que modifiquemos lo que modifiquemos los cambios serán propagados por todos nuestros dispositivos en el momento que estos se vayan conectando.



Ambos sistemas que estamos explicando, pueden ser a su vez ser accedios mediante Polling o mediante Push. Recordar que el protocolo de sincronización es el que realiza la comparación de los datos por así decirlo, pero por encima de ello hay alguien que inicia la transmisión de los datos, que se conecta, que... y al igual que el correo, dado que son accesos directos a los servidores, esto se puede hacer manualmente mediante Polling (Preguntando al servidor si ha ocurrido algún cambio nuevo) o mediante Push si el servidor lo permite, mediante algunos de los sistemas Push que hemos explicado, siendo el más habitual las conexiones abiertas por largo tiempo, al estilo de IMAP IDLE.




-----------------------------------------
-----------------------------------------

Protocolos de Sincronización:


Bueno llegamos a la recta final. Por ahora hemos hablado de protocolos relacionados directamente con cada uno de los tipos de datos que deseamos, algunas veces podremos realizar sincronización y otras veces no. Pero al margen de todo ello existen protocolos de sincronización para ello, al margen de IMAP, CalDav o LDAP. A veces estos protoclos de sincronización usan por debajo estos otros protocolos y a veces usan protocolos propios. Es una forma de estandarizar lo que sería el sistema de sincronización, por ejemplo como se va a usar Push o si se va a usar Polling, que tipo de datos se van a sincronizar... etc.

Aquí aparece el mismo problema. Tenemos protocolos propietarios y protocolos estándares. Vamos a citar 4 en concreto. Volvemos a lo mismo, lo ideal sería que todos usasen protocolos estandares y asi usando el mismo protocolo todo el mundo pudiésemos tener una compatibilidad perfecta. Pero claro, a ver quien es el guapo que le dice por ejemplo ahora a Microsoft que su ActiveSync no vale, o a Apple que MobileMe es una porquería.

Lo normal es que cualquier protocolo de sincronización permita al menos la sincronización de Correo, Calendario y agenda, aunque muchos otros soportan desde notas a archivos de casi cualquier tipo. Vuelvo a repetir que no necesariamente estos protocolos usan IMAP para el correo o LDAP para las agendas. Una cosa es el sistema que usen los servidores para tener los datos o como acceder independientemente a ellos. Otra cosa es muy diferente es esta capa que permite acceso a todos esos recursos para que puedan sincronizarse correctamente con nusetros dispositivos. No se si queda clara la idea.



ActiveSync:

Es el sistema de sincronización de Microsoft. Lleva apostando por él desde hace ya muchos años. En realidad no es un sistema nada malo, permite sincroniazción de casi cualquier tipo de datos, siendo evidentemente los más usados contactos, calendario, correo y notas. Su uso es fundamentalmente en dispositivos portátiles evidentemente, y evidentemente es un protocolo propietario de Microsoft. Muchas veces se usa también el nombre de Exchange, en realidad el nombre completo del protocolo es ActiveSync Exchange. Permite evidentemente funciones de Push, sistemas similares siempre a IMAP IDLE, es decir, conexiones abiertas durente mucho tiempo.



GoogleSync:

En realidad aunque tenga nombre propio, GoogleSync usa ActiveSync, al menos una implementación muy similar a él, de forma que casi cualquier dispositivo que sea compatible con ello, puede usar GoogleSync. Es una tecnología de Google que nos permite sincronizar por ahora Calendarios y Agendas, e incluso da la opción de alertas SMS de cambios. Funcionan realmente bien, el iPhone/iPod Touch es completamente compatible y tengo que decir que una vez más google ha realizado un trabajo genial, nos da conectividad casi con todos los estándares que existen!! LDAP, 3 tipos de accesos diferentes a los calendarios (CalDav, GoogleSync y suscripciones), IMAP y POP para el correo... y ahora GoogleSync para calendario y agenda (de momento) y completamente gratuito. ¿Quien puede pedir más?

Un ejemplo de ello configurado correctamente en mi iPod Touch:



Un ejemplo de Agenda/Calendario sincronizados por GoogleSync y un calendario suscrito de ejemplo además de lo comentado.

Google te facilita los datos propios necesarios:

GoogleSync (Calendario y Agenda, soporta Push):

Protocolo: ActiveSync
Usuario: UsuarioGmail
Contraseña: ContraseñaGmail
Servidor: m.google.com
Dominio: Nada.


CalDav (Calendario, no soporta Push):

Protocolo: CalDav
Usuario: UsuarioGmail
Contraseña: ContraseñaGmail
Servidor: google.com



SyncML

En teoría es el estandar para sincronización que hay. Permite sincronizar prácticamente cualquier tipo de datos, es compatible con Push o Polling... está bastante extendido su uso. Es cierto que al ser casi el único protocolo de sincronización estandar, es normal que muchos hayan optado por esta solución. Pero no todo es bueno... tampoco ha sido muy definido este estandar, dando cabida a muchisimas implementaciones diferentes, tanto a nivel de cliente como de servidores, siendo muchas de ellas incompatibles entre ellas. Por ejemplo, SyncML usa una base de datos, pero esta base de datos no está estipulada y cada cual la implementa como quiere, con lo que un cliente SyncML no tiene porque funcionar con un servidor que usa una BD menos estandar o más rara.

En realidad poco cabe decir de este protocolo. Aunque poco a poco se abre un hueco... le cuesta trabajo dado que protoclos propietarios suelen cubrir la mayoría de las necesidades, dado que la sincronización a día de hoy no suele ser usada en demasía por el usuario medio, cno lo que no se molesta, no lo necesita. El usuario avanzado que lo necesita suele ser pro temas de trabajo, y en consecuencia suele usar simplemente lo que le dicen que tiene que usar, y suele ser un software propietario por comodidad.



MobileMe

Es un invento de Apple para luchar contra ActiveSync y otros protoclos de sincronización. Como no puede ser de otro modo, es un servicio de pago de Apple que requiere de una suscripción anual para poder usarlo. Permite sincronización de correo, calendario, agenda... y espacio en disco. Pero son muchas las razones por las que este servicio no ha llegado a muy buen término, aunque seguro que los mas aferrados a Apple lo usarán y lo defenderán. Lo gracioso es que Apple en un intento de implantarlo comenzó a distribuir en el mismo paquete de iTunes componentes para Windows para MobileMe y referencias a suscribirse y otros... aunque después de la poca verguenza de Apple en incluir en el actualizador de iTunes Safari... sin comentarios.

Primero es un servicio de pago, con lo que ya de por sí es un handicap muy importante, máxime cuando tenemos por ejemplo GoogleSync+Google IMAP IDLE que funciona perfectamenete y que es un servicio completamente gratuito.

Segundo, quien no lo sepa, MobileMe no cifra la conexión!! esto para mi es directamente impensable. Un protocolo de sincronización que no usa una conexión segura?? ¿Estamos locos? Como nota diré que todos los protocolos comentados anteriormente, TODOS, aceptan y usan SSL (encriptación/autentificacion).

Tercero, causa bastantes problemas y errores de sincronización, sujeto a cuelges de los servidores de Apple... en fin.. se han reportado muchísimos problemas por su uso.


-----------------------------------------
-----------------------------------------


Bueno, no tengo más ganas de seguir con esta entrada, creo que más o menos he dejado claro lo que quería expresar sobre sincronización, calendarios, agenda, correos... Así que no dejeis de tener buestros dipositivos móviles y de sobremesa sincronizados!! una sola agenda, un solo calendario y una sola cuenta de correo en todos los dispositivos. En serio, hace la vida muuuuuuuucho más fácil.

Un saludo amigos