I am at Ben Gurion airport now, waiting for a delayed flight and this is a good time to share my experience with different companies.
Lets start from the current one, Tarom. Its a Romanian operator and this is the first and the last time I fly with them. The flight is delayed by 5 hours and I am gonna miss my connection at Bucharest, the next one will be in 8 hours which means that I will miss all the meetings planned for me @Munich and will spend one day in airports instead of being with my family. Its the worst experience ever!
Update: The compensation for this nightmare from Tarom side was ... a voucher for one beverage. They can shove the voucher together with the beverage up their ...es.
Next, Elal. I know its our national carrier and I do feel a pinch of pride when I see the colors on its tail, but since they have gone private the service on Elal flights if terrible. For instance, lets compare inflight beverages. While in Lufthansa I can have everything starting from a water and ending with an Irish cream, in Elal its limited to .... water only. And not just water, a stewardess is coming with a family size bottle of water and pouring it, forget about small bottles .... The attitude if stewardess is awful as well. I know that they are used to Israeli barbaric tourists but they forget that not everyone like this, especially not the folks from abroad who sometimes are shocked ... both by the barbaric tourists and "poorly trained (and its an understatement)" stewardesses.
The latest invention from the cheap bastards at Elal are the "Priority Seats". Every seat that a tall person like me can stretch its feet is labeled with "Priority" sign and to get that seat you have pay extra 50 dollars. I did not see this in any other company I fly with, and I fly a lot. This leads me to the spacing between the rows in economy class ... It looks like it was designed for people with extra short legs. Maybe whoever decided on this has some issues with average and tall people, I do not know.
Now for the good companies.
Lufthansa. Once at HongKong the plane broke down. All the passengers where sent to an airport hotel (which was very good) with appologies, free meals and etc. Later when I boarded they've upgraded me to business as a compensation for the delay .... (Did I say already I wll not flight Tarom ever again ?)
Did you know that when they offer you a drink you can order Baileys and will actually get it for you ?
Turkish Airlines. On long flights they give you a personal kit with toothbrush, socks and etc, even in economy class ... If there is a connection more than 10 hours they offer you a hotel in Instanbul so you could rest (you have to know it ofcourse ...)
Austrian Airlines. The food is delicious. Lots of toys and attention for small children.
There are more but I do not remember. Will update this list when possible.
Tuesday, April 13, 2010
Monday, February 15, 2010
Client - Server protocols and Mobile Platforms
One of my responsibilities @MailVision is the development of CMS - Client Management Server solution. To make a long story short its responsible for distribution and management of mobile VoIP clients for various Mobile platforms such as Symbian, Windows Mobile, Windows, iPhone, Android, Blackberry and more ...
The management part of VoIP clients requires communication between the clients and the CMS server and this is what I will talk about in the current post. The communication had to be lightweight from the bandwidth point of view since usually mobile clients communicate with the server over cellular data links and bandwidth there is rather costly. Another requirement is that the protocol could use secure links (such as TLS/HTTPS) due to nature of data passed between server and the client.
Each platform has its own development language and different implementations of standard and non-standard communication protocols and during past year or two I needed to integrate with all of them. Everything started from Web Services (I know some folks hate it) because it is a default communication protocol between the CMS and its Flex based GUI, so it was only natural to use webservices.
That was the theory at least, webservices worked out of the box only with the Windows based client while failed miserably on Symbian platform. It appears that default webservices toolkit that comes with Nokia has a very llimited support of structured webservices, it does not support inheritance and other data structure available in WSDL. For example it supports enums but list of enums is a total different thing, it crashes with a loud BOOM noise. To overcome we have created a simplified version of objects we expose using webservices, just for the use of Symbian phones and the problem was solved (it took lots of time to understand what exactly Symbian does not like and it was not an easy task). Since then we have switched to GSOAP on the newer Symbian phones which seems to support webservices much better, but still its a pain in the ...
Next platform that was needed to be supported was Windows Mobile. There we used GSOAP with the simplified layer and it worked without any significant problems ... The only problem is that no one uses Windows Mobile these days :-)
iPhone was next in line and webservices is a complete nightmare on iPhone OS so it was decided that another protocol should be selected which support will be acceptable by both Java server side and iPhone client side. After some research I've have selected Hessian as a leading candidate and indeed it took only several days to introduce a Hessian doorway on the server side and two more weeks to support it on the iPhone.
Lets make a headcount, till now server supports webservices and hessian.
We go on. One the MailVision solutions is a WebLynx (which was covered in this blog before) and it also had to be integrated with the CMS. Whats different about this integration is that its not client-server protocol but rather server-server protocol since WebLynx is also a Java based server. Since I learned to dislike webservices by then I decided to look for alternative which appeared in form of Google Protocol Buffers combined with Apache Mina. Its a great best of breed for the type of communication we required and several days later and couple of PB descriptor files the solution was ready and performance tests showed great results.
Headcount - Webservices, Hessian and Protocol Buffers.
Android. In order not to re-invent the wheel we decided to use good old Hessian which proved to be not a complicated task (nothing to do from the server side since it was already written :-) )
No change in the headcount.
Blackberry. The Java version in the Blackberry devices is J2ME on steroids but its very limited. Using Hessian there as we did on other platforms is troublesome and complicated since it misses the required language functionality such as introspection and reflection which are in the core of Hessian. Microhessian is not enough for our needs. Back to drawing desk. After trying different approaches and inspecting existing J2ME implementations the best candidate was JSON which was selected at the end. JSON over HTTP(S) answered the bandwidth/security requirements.
Final headcount till now - Webservices, Hessian, Protocol Buffers and JSON.
More to come :-)
The management part of VoIP clients requires communication between the clients and the CMS server and this is what I will talk about in the current post. The communication had to be lightweight from the bandwidth point of view since usually mobile clients communicate with the server over cellular data links and bandwidth there is rather costly. Another requirement is that the protocol could use secure links (such as TLS/HTTPS) due to nature of data passed between server and the client.
Each platform has its own development language and different implementations of standard and non-standard communication protocols and during past year or two I needed to integrate with all of them. Everything started from Web Services (I know some folks hate it) because it is a default communication protocol between the CMS and its Flex based GUI, so it was only natural to use webservices.
That was the theory at least, webservices worked out of the box only with the Windows based client while failed miserably on Symbian platform. It appears that default webservices toolkit that comes with Nokia has a very llimited support of structured webservices, it does not support inheritance and other data structure available in WSDL. For example it supports enums but list of enums is a total different thing, it crashes with a loud BOOM noise. To overcome we have created a simplified version of objects we expose using webservices, just for the use of Symbian phones and the problem was solved (it took lots of time to understand what exactly Symbian does not like and it was not an easy task). Since then we have switched to GSOAP on the newer Symbian phones which seems to support webservices much better, but still its a pain in the ...
Next platform that was needed to be supported was Windows Mobile. There we used GSOAP with the simplified layer and it worked without any significant problems ... The only problem is that no one uses Windows Mobile these days :-)
iPhone was next in line and webservices is a complete nightmare on iPhone OS so it was decided that another protocol should be selected which support will be acceptable by both Java server side and iPhone client side. After some research I've have selected Hessian as a leading candidate and indeed it took only several days to introduce a Hessian doorway on the server side and two more weeks to support it on the iPhone.
Lets make a headcount, till now server supports webservices and hessian.
We go on. One the MailVision solutions is a WebLynx (which was covered in this blog before) and it also had to be integrated with the CMS. Whats different about this integration is that its not client-server protocol but rather server-server protocol since WebLynx is also a Java based server. Since I learned to dislike webservices by then I decided to look for alternative which appeared in form of Google Protocol Buffers combined with Apache Mina. Its a great best of breed for the type of communication we required and several days later and couple of PB descriptor files the solution was ready and performance tests showed great results.
Headcount - Webservices, Hessian and Protocol Buffers.
Android. In order not to re-invent the wheel we decided to use good old Hessian which proved to be not a complicated task (nothing to do from the server side since it was already written :-) )
No change in the headcount.
Blackberry. The Java version in the Blackberry devices is J2ME on steroids but its very limited. Using Hessian there as we did on other platforms is troublesome and complicated since it misses the required language functionality such as introspection and reflection which are in the core of Hessian. Microhessian is not enough for our needs. Back to drawing desk. After trying different approaches and inspecting existing J2ME implementations the best candidate was JSON which was selected at the end. JSON over HTTP(S) answered the bandwidth/security requirements.
Final headcount till now - Webservices, Hessian, Protocol Buffers and JSON.
More to come :-)
Subscribe to:
Posts (Atom)
