2. XML can have performance issues and it can be slow to process.

We don’t mean to be rude in our rely here but it is important to answer some of your suggestions. Ultimately, we hope it makes a good discussion. Do keep in mind that Hiitch is not a web server nor does it implement the web protocols.

“1. You should be able to support secure connections via proxies,”

Proxies leak information and becomes a big security risk for private data. Unless we want to be anonymous, then we would want to use techniques like proxy chaining, which we agree. But unless the proxies belong to us, the chances of our client’s information falling into the hands of 3rd parties are extremely high. Snooping can be easily done on these external proxies by caching the information that goes in and out of them and those cached information can then be decrypted at a later time, if needed.

“don’t rely on SSL for security, clients should send/receive all data by web get and post connections (persistent if possible), just be tricky with extra public key encryption, compression and network details to frustrate snoopers and impersonators i.e. a pull based architecture.”

We don’t rely only on SSL. The key worry of SSL is on the server identity verification. We use digital signature verification and unique server IP to identify each network which will allow clients to connect only to their particular network. Your suggestions merely hope to slow down the hacker but does not attempt to solve the problem.
You can read more about our security features at http://www.hiitch.com/blog/2007/02/14/how-secure-is-hiitch.

By the way, get and post are for web servers and are suitable for the purpose in which they are designed. Hiitch requires more than what they can offer hence our approach uses techniques similar to RPC (remote procedure call).

“2. XML can have performance issues and it can be slow to process.”

Our testing has shown that a simple Hiitch session XML request can be completed in the range of 90 milliseconds on our entry class server (connection time included, LAN), which is fast enough for our purpose of use.

And yes, XML is slower to process, we agree. We have no doubt about that but as for causing performance issues, that will depend on what you are using it for. It is all about finding the best solution that meets our needs. In any solution there will be pros and cons but if the pros out weigh the cons for the purpose that we want to achieve than it is acceptable to us.

If we were concerned merely about performance issues only, than we will not even use TCP (hence, post and get) as our transport protocol. UDP is a far more faster protocol to use because it does not have the connection overheads of TCP.

Thanks for your interest to help make Hiitch better.