pill.cat communication 2.0

In the next version we will be using XMPP messaging protocol instead of e-mails. But in fact e-mail will remain as backup and a lot of features will keep using it such as the "pill it" web button, because it is asynchronous.
But it will be enough to check the mailbox way less frequently (every 10 minutes for example) which will decrease both network and client load.

The following diagram depicts the overview of the new architecture. I know it looks quite similar than the previous one, but it looks nicer due the better tool I used to draw it and of course it is very different. I explain the differences right after the image.

pill.cat network architecture overview

As you can see there are a pill.cat server on the image with a huge database sign. This also means that we are having a centralized approach here. This is because we need to have a registry of all users including their addresses and in the future their reputation values according to skills and topics. If you want to know more about the reasons please read the previous post. 

The communication between the clients (pill.cat agents and human users using desktop applications) is done via Google's services. The reason why is that it is reliable (so far), scaled up enough, well documented, free and of course we don't need to maintain. The drawback though is that we are relying on 3rd party. But here is the answer, as we can not stand it any-more we can switch to own servers using open source XMPP solutions in no time. Than you can substitute the name of Google with pill.cat infrastructure. 

Of course from that time all scaling and maintaining is ours, so it might be a good idea to have some p2p solution at that time, although we always will need central entities in order to keep yellow pages and other cool stuff up.

But how does it look like in practice? This is what the following posts will explain in detail.