Difficulties of synchronizing google calendar with google data protocol.

First I want to emphasize, that it is important to user the most recent version of clients libraries, because google protocol is still develeped and some version are quite insufficient (especially that included in debian linux).

Google data protocol currently have three versions. I have only considered using version 2 and 3. I suppose that version one is quite obsolete. Version 3 is based on JSON, which is great because no parsing is needed, but that version provides no support how to chain commands together in batches. Also the client libraries does not include the last version support. Running commands in batches is quite important because there is quite big net roundtrip for each request. So without batches you are forced to implement sending asynchronious requests. I am not sure if one batch request counts as one in google limits, but their are quite comfortable. Because I have been in developping the synchronization through the protocol version 2 when the next version was introduced I stucked with the older version so I hope that some information will hold even for next version.

Major obstacle in protocol version 2 is that recurrent events are represented in diffferent format than normal events. Normal events are represented in atom xml, which is parsed by GData library. Recurrent events is represented in iCalendar format and you have to parse it yourself. Therefore you have to implement two parsers and writers and not only one.

Next obstacle is that recurrent events can have exceptions. In iCalendar that exceptions is represented by EXDATE, what is sillently ignored by google. The Google calendar web aplication fortunately understands but fails to mark. So it is left to you. When you remove one occurance of event from recurrence or update it, the new event is created which has link to recurrent event which modifies. The original event is not modified - its etag remains same so without founding the recurrence exception you do not even know that, the original event recurrence does not hold. I came even to situation where the original event does not existed, but the recurrence exceptions was still accesible. Its up to you how you we will represent such behaviour in your data model. Moreover I forget to mention that when you delete original recurrence all exceptions are deleted as well and same hold even for some modifications of original event.

Third obstacle is that the google sometimes lies to you, so you have to learn to ignore problems with denied authorization for authorization values which does not changed and starts to work in the next request. Also sometimes you are redirected elsewhere, but stubborningly replying requests helps :).

The last small obstacle is that you cannot undelete or modify deleted items on Google. I am solving it by creating new ones instead of deleted ones.

So you can say, google also provides CalDAV access, why not go with it? Yeah good try, but you will also meet all previous mentioned obstacles. Not to mention that authorization will fail to work not for one request but for days and after some time it will start works without any change. And of course forget authorization with OAuth, you will have to send plain text password. A big "no way" for any server. At least the google will inform a user that your server tryies to access his account with his credentials. So prepare plausible explanation that you have not let his password to be stolen.

Should I write more about google calendar?

Limit výtahů na výšku mrakodrapů

Do vynálezu výtahu nebylo praktické stavět obytné budovy nad určitou výšku - někomu se nechtělo cestovat po schodech. Zajímavé je, že i výtah klade omezení na smysluplnou výšku obytné budovy. Čim výšší budova, tím větší část její plochy je věnované výtahovým šachtám. Od určitého patra výtahy zajištující dopravu do tohoto patra zabírají v budově větší plochu, než celá plocha patra a nemá tedy smysl snažit se další patro přidávat.

Plocha kterou sptřebují výtahy pro dané patro je dána počtem pater přes které se musí cestovat, což je většinou od paty budovy, a množstvím výtahů nutným pro dopravu lidí do tohoto patra ve špičce. Je zřejmé, že čím jde o vyšší patro, tak výtahu trvá déle překonat danou vzdálenost a pro dopravu stejného množství lidí za jednotku času je potřeba více výtahů (nebo jejich větší plocha).

Celkově lze tedy říci, že plocha zabraná výtahy pro patro P je kvadraticky závislá na P. Zajímavé je, že tohoto ekonomického limitu už dnešní budovy dosahují. A snaží se mu vyhnout rychlejšími výtahy, více výtahy v jedné šachtě a více patrovými výtahy. Přesto všechna tato zlepšení zvyšují kapacitu výtahů násobně a tedy pomáhají jen zvýšit limit o odmocninu koeficientu zlepšení účinosti výtahů. Tedy dva dvoupatrové výtahy v každé šachtě zvýší možný počet pater v budově maximálně dvounásobně. Zároveň je potřeba počítat i s dalšími limity. Jako je rychlost změny tlaku, během cestování výtahem, rychlost s jakou se lze dostat na vrchol budovy (a zároveň jak rychle lze budovu opustit) a dalšími produktovody v budově - jako je např. rozvod pitné vody a sběr odpadních vod.

Zajímavá čísla

• cca 0.25m² velikost podlahové plochy výtahu na osobu

• 0.057 počet osob na m² patra kancelářské budovy (World Trade Center - Twins towers 25k osob na věž, 110 pater, 4020m² podlahové plochy dle wikipedie).

• 60km/h rychlost výtahu v Petronas Towers v Malajsii.