More and more people are using more and more devices across more and more networks. We routinely use one or two different desktops and carry along a laptop plus a mobile phone and eventually other gadgets. All with different user interfaces, supporting various protocols, and more often than not we found ourself juggling with identities and network configurations...
This is thus very tempting to give up and sell our numeric soul to a company that will handle the hassle of managing all the software for us, and provides us with a unique identity and a simple all-in-one web interface.
The first problem with this is that you become very closely tied to this particular vendor.
The second problem is that you must conform to the planned usage.
The alternative is to use your own unified communication system. I'm afraid this is not viable either.
Traditionally, unified messaging software and usages are based on emails : calendar events, contacts or tasks are handled as special kind of emails. Also, many people daily use emails as a general purpose file sharing tool.
But the everything is an email abstraction does not work well :
Real time communications are generally handled with SIP with some machinery to share a contact list with the email server. This machinery grows exponentialy with the number of additional servers you want to "unify". This is unsustainable.
To work around the former objections one generally uses IMAP. IMAP allows to store the emails in a friendly hierarchy of folders that can be shared amongst several users.
Anyway, IMAP has indeed some limitations :
To sum it up : IMAP is too widely used, too important and too big to be adapted.
We definitively need something new, that is protocol-agnostic and suitable for realtime communications as well as classical message synchronisation. This is why this Scambio project was started.
What's good about IMAP is that it mimics a remote file system, which offer to users a familiar way to classify their messages. Also, is distinguishes between message meta datas (the header) and message content, allowing for instance the user to judge if a message is worth the download by inspecting the header first. So why not go further this path ?
For Scambio, there are two kinds of information :
Scambio never looks at the files and barely looks on the meta data neither. Only the meta datas are synchronized in realtime while the files are kept in a central place and only cached on the clients.
Files can be referenced at no cost from different folders like UNIX hard-links, and read while still being written to in real time like UNIX named pipes (to allow realtime communications).
A messaging system must be a tool to allow users to share information the easiest way. It must not impose any usage pattern nor any structure on a transported message (yet the addition of meta data allows receiving device(s) to interpret it as intended). Users must be able to easily add handlers and connectors to various external protocols, because if some of them are already known (SMTP, SIP, Jabber...) most of them are yet to be invented.
Mobile devices, especially free ones, have the potential to give rise to many new communication usages. Only a free software license allows users to twist the tool to new needs.
But let's face it : this is not enough to open the source code. Many open source products nowadays require a dedicated team of developpers to be merely maintained. They are no longer under the range of the average single hacker, who will certainly not want to spend more than a few nights on a project to add a feature. Thus, in order to be useful for the community software complexity must be kept particularly low. A free software must be properly documented, well designed, easy to build and last but not least : small.
The KISS principle must prevail !
Users receive messages in several devices. It is then simpler to choose a centered model, where these devices connect to a central server which holds the messages until explicit deletion. Devices are not expected to store more than a cache of (some of) the messages. Very similar to IMAP so far.
Users devices also send new messages/calls through this central server. In appearance users just add a message to their send box (header + optional content), the central server being responsible for the actual delivery/communication establishment. This allow the users to keep a copy of what's sent, and is more easy both for the user and the devices software, which does not need to worry about several transport protocols any more.
So this central server must handle conversions in both ways : from transport protocol X to (one or several) scambio meta data sample(s)/file(s) and from one (or several) scambio meta data(s)/file(s) to transport protocol X. But from this server to the client the only transport that takes place is mere metadata synchronization.