90di travel search blog

Backward compatibility for the human mind…

Don’t worry, its not a post on psychology. Just a whacky title.

Not just systems, but humans (and by extension data) too needs backward compatibility. Case in point the Train numbers have changed from well over a month. But lots of users are still searching for the old numbers:





And also, Got one feedback yesterday, which said:
“i asked for rail fare, it gave result for flight…”

search query pertaining to above feedback was:
rail fare of 2433, rajdhani express

What was happening in this case was, since it got a flight with no. 2433. It unwittingly showed the results of the same.

So hey you anonymous friend, who got us to act, thanks! And some good news for you, and also to other users, who must have been suffering in silence. We made a change so you can search like this also, for as long as you like. And when you do get used to the new numbers, that are of course supported as well.

Tags: , , , ,

3 Responses to “Backward compatibility for the human mind…”

  1. Deepak Says:


    I see that there is no blog for this month. you must be thinking something new to put on.. fans are waiting for you to pen down.
    Also, i hope you must remember that i am also working on gwt 2.1 for some client in africa as we had discussed earlier. I think i need to share some of my experience/difficulties with you regarding gwt.
    Thesedays i am doing code splitting for my project but i find it quite difficult to split code properly as at the end i find a big chunk of code for start up time.
    I see on your portal that you have done the code splitting very well as you have only 40 kb at the end.
    i request you to kindly share some of your experience/ideas how to do achieve this properly. If possible put some dummy code as an example.

    Waiting for your reply.


  2. khushnood Says:

    Hi Deepak,

    Welcome back! Apologies for the late reply.

    Yes, sure, will try and post soon.

    Yes, I do remember you working on GWT. The way we do it, is briefly, as follows:

    1. Our home page is very light, and has very little GWT code.
    2. We have broken the GWT code, into various modules. Example for route search there is one, trip planner another and so on.
    3. The dependent modules, share a common module. For some common util stuff (e.g. date/time fns) and any travel specific fns. Or any shared UI forms (which is rare, may be calendar is an exception)
    4. We figured that, its easy to link to some other module accidentally. Which basically would mean that the dependee module also gets loaded, and you don’t want that.
    5. Broadly our modules are something like this. For example: A (home page) – and it should not depend on any other module. B (common module), C (Search UI module), D (trip planner module)
    – You have to ensure, by mistake A doesn’t depend on B, C or D.
    – Similarly C, should not depend on D.
    6. We follow some custom java packaging convention of our own: e.g. module.A should never depend on module.A.B . But module.A.B can depend on module.A
    7. We have a small program, which gives compile error, if there is any such rule broken. This program is invoked by the GWT build script.
    8. Also we have written custom module loaders for each module. This allows having access to the loaders, from the java script. (May be you won’t need this)

    May be could have done a blog post on this aspect of GWT. GWT as such is great. But one single flash like ‘blob’ – for an app, is the main peeve, we share with you. Hopefully, they can tackle this in a neater way, in the coming versions.

    Please feel free, to ask more questions. Happy to help.


  3. Deepak Says:

    Hi Khusnood,

    Thanks for your input. And as you told, pls do a blog post on this aspect of GWT with some example code.


Leave a Reply

CAPTCHA Image Audio Version
Reload Image