-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Hello,
Thanks for making such awesome project available to the rest of the world ;)
I love the idea and agree on the server-client architecture part, but building such complex software one should also think about scalability. I currently have no idea, who are the main users of RC, but we should assume that the new solution should work flawlessly with thousands of mailboxes accessed simultaneously.
NB: Since I'm a sysadmin for a hosting company I'm writing everything from the hosting provider view.
NBB: I might sometimes use a bit of imperious/authoritarian phraseology (should, must etc), so please don't be offended, it's just like I write
- probably from reading too much RFCs :)
NBBB: Also, I have ended a some sentences with question mark, I don't want answers for those "questions", these are more like parts "what if" style things ergo my brain going into cosmos of ideas.
### Back-end
To be honest, connection caching isn't really an issue for me, there are utils specifically designed for that (local imapproxy), so are there good ways to fasten the authentication process (local Nginx IMAP proxy with HTTP authentication to Nginx http server with custom auth script, makes it also possible to load balance). Yes of course it would be better, if back-end could do those things, but the question is, that can we do it better and with less performance and development time cost than existing software? Or instead it we could use this time to make a documentation how create a good performance RC setup using the existing technologies?
Creating such complex back-end one also should take in mind that it should be possible to load balance it - run multiple back-end servers which communicate with each other. Keep in mind, that in the future the backend could be directly used by mobile apps, desktop clients, user made scripts, or even by your refrigerator - that's one of the point of making separate back-end server.
Back end should be extendable by plug-ins and this raises a lot of questions. Someone just don't want the back-end with by default calendar support. Some even don't use address-books. Maybe someone wants to make a plug-in to create friends list, how will actions and data described for the protocol for that plug-in? How strict will be? How to avoid protocol conflicts?
Also, as for data caching (eg Redis) one should think about the stored data. Is it mostly key-value based or does it require complex relations 1? What data will be cached?
### Back-end language
OK, so question #1: what's your take on the programming language choice?
The eternal question of which language is the best.
PHP has good enough performance, sorry to disappoint You, but "good enough" just don't do on large systems. You have to have best performance You can get. Also, my personal opinion is (as a long time developer), that if I'd had a time machine the programming language which I would make disappear is PHP (next one will be of course Javascript :).
I'd go with Python. Easy to write (and IMHO more supported than Node.js) and in my experience it runs long-term processes spotless unless You write it bad. Most *nix systems have it on by default as dependencies for providing any web services at all (same with Perl). Plug-ins could easily be installed as Python Packages using pip. Lots of well documented and stable libraries for network communication with protocol definitions. I have been PHP dev longer than Python dev and I'd prefer Python any time. Some say Python is hard to learn (yes, we have many PHP devs out there, more than Python's). IMHO a good dev can write any language and also, we can always make a good documentation.
Node.js - sorry, it might be good but first, it's javascript - who even uses javascript for back-end and second, it seems too hipster for old me. Usually needs a separate installation unless you are providing as part of hosting service.
Large number of hosting providers do not allow long lasting scripts for their clients (in virtual/shared hosting). Max execution times are usually about 5 minutes (10 mins max). Therefore running any server applications in virtual/shared hosting is not possible (most of common clients use shared hosting). So taking this in consideration the "PHP is everywhere" is quite useless in my opinion, since You probably need VPS for client-server application anyway and there You can install anything You want.
On the other hand, most of clients use the webmail provided by hosting provider (who has capabilities for complex set-ups).
### Front-end
For frameworks I would recommend Backbone.js for structure and data modeling and Twitter Bootstrap as UI toolkit.
Does keeping back-end and front-end separate would also mean that every plug-in developer must release the back-end and front-end version of their plug-in or will the protocol support UI data transportation (eg client will request UI data from back-end and then caches it)?
### Data model
Creating the data model should we take in consideration that maybe there are people, who only would like to use the company's global calendar and address-book without any e-mail? Just log in to see company's contacts. Maybe they want to add personal mailbox later? The model should be abstract as possible, but extendable by various plug-ins. Even authentication methods (IMAP, HTTP, Kerberos, government issued ID-card etc) should be provided as plug-ins.
The only thing that is certain, is that we have some abstract "client" (not a physical entity) what will have all the provided services (mailboxes, calendars, contacts, identities?, chat messaging system etc).
Every client can have one or more users (company "clients" can have more than one for example). Users with authentication and authorization methods defined by specific plug-ins designated to those actions and handled via strictly defined User API. We also should keep in mind that the required data should be as little as possible, since many auth protocols don't support mother maiden name or even address. Strictly data required for authentication and authorization.
### Protocol
For the sake of simplicity, I think that using HTTP protocol would be the easies way to go. Yes, it's overhead, but on the other side it's easy to handle and develop on. And for the architecture REST is a good way to go. Well documented, easy to use.
Best regards, Günter Kits