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 :-)
Monday, November 23, 2009
PicoSocial
New addition to the Pico family. I am proud to present the PicoSocial Facebook application.
As its brother, PicoWave, it enables online voice conversations between online users, the friends of the user who installed the PicoSocial application and as PicoWave its also built on the WebLynx solution which VoIP enables everything it touches.
The application is right now a alpha stage but already can be used by anyone who likes to experience.
Facebook applications is a more richer ground for application features then the Google Wave one, because of Facebook of course. It allows interaction not only with online friends but with friends who never installed PicoSocial application. One of the models for application usage can be placing outgoing calls (like SkypeOut) to the friends who shared their phone numbers (or mobile phone numbers). Incoming calls to the online users is also an option.
If you want to try the application use this link:
http://apps.facebook.com/picosocial
You comments and thoughts you can leave here or email to picosocial@mailvision.com.
Follow the application on @picosocial for twitter updates.
As its brother, PicoWave, it enables online voice conversations between online users, the friends of the user who installed the PicoSocial application and as PicoWave its also built on the WebLynx solution which VoIP enables everything it touches.
The application is right now a alpha stage but already can be used by anyone who likes to experience.
Facebook applications is a more richer ground for application features then the Google Wave one, because of Facebook of course. It allows interaction not only with online friends but with friends who never installed PicoSocial application. One of the models for application usage can be placing outgoing calls (like SkypeOut) to the friends who shared their phone numbers (or mobile phone numbers). Incoming calls to the online users is also an option.
If you want to try the application use this link:
http://apps.facebook.com/picosocial
You comments and thoughts you can leave here or email to picosocial@mailvision.com.
Follow the application on @picosocial for twitter updates.
Saturday, November 14, 2009
Google Wave extensions (gadget) development with Adobe Flex
Recently I've developed a Google Wave extension (gadget) using Flex and in the following post I will try to help people that are thinking of doing the same, to save some time and headache by not repeating the pitfalls I've encountered.
1. If you are developing an Extension with Flex you are most likely will want to communicate with the wave framework. This is done using Javascript.
Google included an API to embed Flash objects in the wave but the API is non sufficient for the extension development. It does not let you pass the required parameters to the SWF. The workaround is using javascript (not Google Wave APIs) ones like you would do normal regular flex SWF in HTML. My suggestion is to look on the HTML wrapper files generated by Flex Builder and use the Javascript functions from there. For example to embed SWF file named "test.swf" you will have to do the following:
AC_FL_RunContent(
"src", "http://hosted.somewhere/test.swf",
"width", "350",
"height", "400",
"align", "middle",
"id", "flexId",
"quality", "high",
"bgcolor", "#869ca7",
"name", "flextId",
"allowScriptAccess","always",
"enablejs", "true",
"type", "application/x-shockwave-flash",
"pluginspage", "http://www.adobe.com/go/getflashplayer"
);
Please note the "allowScriptAccess" directive. Using this you will be able to call javascript from Flex and Flex from javascript.
Next step is too allow javascript access from the HTML to SWF. You have to allow it in the Flex code by including the following code somewhere in the application initialization:
Security.allowDomain("*");
This is required since the SWF is being executed from a different domain its hosted on.
After following the above you will be able to use javascript and to embed the SWF object.
2. How do you call Flex from Javascript and Javascript from Flex ?
From Flex to Javascript:
Lets assume you have a function fooJs() defined in your Javascript in the HTML wrapper.
To call it from Flex you will have to:
if (ExternalInterface.available)
{
try {
ExternalInterface.call("fooJs", null);
}
catch(error:Error) {
}
}
The other way around, lets assume once again that you have a method called fooFlex() in your Flex code. To call it from Javascript you first have to register a callback to the method in your Flex application:
if (ExternalInterface.available) {
try {
ExternalInterface.addCallback("fooFlex", fooFlexImpl);
}
catch(error:Error) {
}
}
public function fooFlexImpl(params:String):void {
// Actual Flex impl.
}
Then you can call it from javascript:
document['flexId'].fooFlex(someParam);
Ok, following this will save you at least few hours, I hope. Now you can use Google Wave API to pass status and participants updates to your Flex application and do status updates from your Flex application.
If anything is unclear or you need additional info, do ask.
1. If you are developing an Extension with Flex you are most likely will want to communicate with the wave framework. This is done using Javascript.
Google included an API to embed Flash objects in the wave but the API is non sufficient for the extension development. It does not let you pass the required parameters to the SWF. The workaround is using javascript (not Google Wave APIs) ones like you would do normal regular flex SWF in HTML. My suggestion is to look on the HTML wrapper files generated by Flex Builder and use the Javascript functions from there. For example to embed SWF file named "test.swf" you will have to do the following:
AC_FL_RunContent(
"src", "http://hosted.somewhere/test.swf",
"width", "350",
"height", "400",
"align", "middle",
"id", "flexId",
"quality", "high",
"bgcolor", "#869ca7",
"name", "flextId",
"allowScriptAccess","always",
"enablejs", "true",
"type", "application/x-shockwave-flash",
"pluginspage", "http://www.adobe.com/go/getflashplayer"
);
Please note the "allowScriptAccess" directive. Using this you will be able to call javascript from Flex and Flex from javascript.
Next step is too allow javascript access from the HTML to SWF. You have to allow it in the Flex code by including the following code somewhere in the application initialization:
Security.allowDomain("*");
This is required since the SWF is being executed from a different domain its hosted on.
After following the above you will be able to use javascript and to embed the SWF object.
2. How do you call Flex from Javascript and Javascript from Flex ?
From Flex to Javascript:
Lets assume you have a function fooJs() defined in your Javascript in the HTML wrapper.
To call it from Flex you will have to:
if (ExternalInterface.available)
{
try {
ExternalInterface.call("fooJs", null);
}
catch(error:Error) {
}
}
The other way around, lets assume once again that you have a method called fooFlex() in your Flex code. To call it from Javascript you first have to register a callback to the method in your Flex application:
if (ExternalInterface.available) {
try {
ExternalInterface.addCallback("fooFlex", fooFlexImpl);
}
catch(error:Error) {
}
}
public function fooFlexImpl(params:String):void {
// Actual Flex impl.
}
Then you can call it from javascript:
document['flexId'].fooFlex(someParam);
Ok, following this will save you at least few hours, I hope. Now you can use Google Wave API to pass status and participants updates to your Flex application and do status updates from your Flex application.
If anything is unclear or you need additional info, do ask.
Thursday, November 12, 2009
Why Flex and not Ajax
Some time ago, my CTO asked me a question: "Why do we develop GUI using Adobe Flex and not some Ajax toolkit ?".
Following is list of reasons I compiled, maybe someone will find it helpful when being asked the same question:
Following is list of reasons I compiled, maybe someone will find it helpful when being asked the same question:
1. Its a technology we have more than 3 years of development and design expierence with.
2. Established community and plenty of forums are available.
3. Cross browser, cross OS.
4. Eye candy with almost no effort.
5. Can be executed as a desktop application (AIR).
6. Very good client-server interaction . (Blaze DS, Granite DS)
7. Solid development tools - Flex Builder, Intellij.
8. Good object oriented development language. (actionscript)
9. Very good debuging and profiling tools which is very important in GUI development.
10. Flex's graphs and reports framework.
11. Very good webservices toolkit.
12. Media streaming capabilities (Red5).
PicoWave
Everybody are excited about Google Wave, so am I.
Today I've released a Google Gadget that VoIP enables the waves so that all the wave participants can speak (voice, words, vocal) between each other.
The Gadget is based on MailVision product that is called WebLynx. Its partially server and partially client based product. On the client side its a flash SWF file (built with Adobe Flex) that communicates with our server using proprietary API and Flash audio codecs (NellyMoser and Speex). From there its SIP/RTP to the nearest SoftSwitch and on the world.
The PicoWave gadget variation enables calls between wave participants and no outside world calls although we are planning to extend its functionality and add incoming calls to Waves and outgoing calls to PSTN from within the wave, all depends on the interest to the gadget.
Its a first gadget of this kind in the market and we are very excited to release it and to see the feedbacks it will produce.
You can follow the gadget news on Twitter as well. The Twitter name as you might have already guessed is "picowave".
On a later posts I will write down my experience developing this gadget.
Now, to use the gadget you should do the following:
1. Add the gadget to the wave by URL:
http://picowave.mailvision.com/picowave.html
2. Add Google Wave extension using the following manifest:
http://picowave.mailvision.com/manifest.xml
Some quick HOWTO:
1. Take a seat
2. See all online participants
3. Click participant to call him.
If you are alone in the wave and still want to try the gadget you can call our echo service that is always in a seat waiting there just for you :-)
Your comments please leave here, send my mail or Wave it in our public testing wave which you can find by searching for "tag: PicoWave with:public".
Follow the application twitter @picowave.
Now, to use the gadget you should do the following:
1. Add the gadget to the wave by URL:
http://picowave.mailvision.com/picowave.html
2. Add Google Wave extension using the following manifest:
http://picowave.mailvision.com/manifest.xml
Some quick HOWTO:
1. Take a seat
2. See all online participants
3. Click participant to call him.
If you are alone in the wave and still want to try the gadget you can call our echo service that is always in a seat waiting there just for you :-)
Your comments please leave here, send my mail or Wave it in our public testing wave which you can find by searching for "tag: PicoWave with:public".
Follow the application twitter @picowave.
Starter
Its my first post so let me tell something about myself.
My name is Dima Gutzeit and I work for a company called MailVision. We are making VoIP related products including servers and clients, the whole range, you name it.
My job is the Team Leader of the Server side products @ MailVision R&D.
In this blog I will post interesting developments and problems I came across and solved as well as other things I am passionate about (like the products we make for example).
Thats it for now.
P.S. - My twitter name is "@dgutzeit".
My name is Dima Gutzeit and I work for a company called MailVision. We are making VoIP related products including servers and clients, the whole range, you name it.
My job is the Team Leader of the Server side products @ MailVision R&D.
In this blog I will post interesting developments and problems I came across and solved as well as other things I am passionate about (like the products we make for example).
Thats it for now.
P.S. - My twitter name is "@dgutzeit".
Subscribe to:
Posts (Atom)
