Off topic, but since I worked at Kayak let me expand a bit on its relationship to ITA as I understood it.
Airlines and hotels had data about flights and available rooms. Kayak needed this data to show it in your search. This could happen in a few ways:
1. The airline or hotel could send Kayak data that had a particular format, and Kayak would deal with it. A common format, especially for hotels IIRC, was invalid csv files.
2. The airline could send its flight data to ITA, which standardized it across all airlines that used the service. ITA was a separate company from Kayak and Google flights and other flight search engines; it aggregated data but was not a search engine. [EDIT: was not primarily a search engine. See comment below.] Kayak would buy data from ITA.
3. The airline or hotel could decline to let Kayak list its flights/rooms.
Since then Google bought ITA, breaking the [EDIT: partial] separation between the most common flight-data aggregator and flight search engines. (Which was probably good for competition; I was a little concerned about the merger.) And Kayak was bought out too, by one of its competitors.
Take all this with a grain of salt: this is what I remember from years ago, and it wasn't really my area. And I certainly don't speak for Kayak.
Not to mention almost all US based carriers and many others use ITA's flight search service to power their own (the carriers') websites. They can't search in the data they created, so they have to pay ITA.
The data is complicated and many-sourced. Fares and rules come out of ATPCO. Flights are separate from a different supplier. Seat availability is a massive collection of data morphing at 10 Hz, and it has nothing to do with whether seats are available. Then there is taxes and government fees which I think are now ATPCO, too. The timezone file I have seen at ITA still beats any other timezone collection I have ever seen. It's busy over there and the wires are glowing.
>"Not to mention almost all US based carriers and many others use ITA's flight search service to power their own (the carriers') websites. They can't search in the data they created, so they have to pay ITA."
Can you say why aren't carriers able to search in the data they created without using ITA?
You have to realize the difference between a "pricing search" and a "low fare search", to use ITA terminology.
A "pricing search" knows which specific flights it goes through and you just find the fares (keep in mind the carriers file like 600 fares for planes with 20 seats). The airlines could always do that. Before ITA came along in 2001 or so that is what you were waiting on in the travel agency while the agent tries different flight combinations by hand.
"Low fare search" is also finding the flights. The carriers could not generally do that without ITA. There are exceptions such as Southwest which had a fare structure more like buses that kept the combinatorics down.
But in addition to the immense amounts of fare and rule data that pile on your if you search 400 itineraries out * 400 back you also have the seat availability system. No carrier had (probably has) a system that can answer the amount of "seat" queries that a single low fare search causes.
Keep in mind "seat availability data" has nothing to do with what seats are available. It is a high-frequency (10 Hz or whereabouts) way to turn fares on and off.
>"A "pricing search" knows which specific flights it goes through and you just find the fares (keep in mind the carriers file like 600 fares for planes with 20 seats)."
Wow why so many? This seems excessive?
Could you elaborate on:
>"But in addition to the immense amounts of fare and rule data that pile on your if you search 400 itineraries out * 400 back you also have the seat availability system. No carrier had (probably has) a system that can answer the amount of "seat" queries that a single low fare search causes."
I didn't understand the "400 itineraries out * 400 back you also have the seat availability system" part. I din't understand the math and how it enables a "seat availability" system.
Lastly are all of the limitation really due the legacy Sabre booking system that the carriers all use? I guess I didn't realize what a huge innovation ITA was.
Interesting! I wonder why ITA never offered a search engine themselves, if they had all the data aggregated. And boy do I love dealing with invalid CSVs... (especially ones that contain commas within the fields by accident)
I want it noted that this thing is really neat — you can provide parameters like min layover of 2 hrs, or 2 weeks, and even search only within a particular airline alliance
There are some feature in matrix that flights didn't pick up. The original matrix site was even more powerful and exposed some operator-ishness, depending on what kind of account you were granted.
I suspect that branding is powerful, so it's better to keep an existing flight search running than to axe it in favor of something else and loose all the existing customers. Google bought ITA and kept matrix.itasoftware.com running with (presumably) the same branding; Booking Holdings bought Kayak and kept kayak.com running with the same branding.
Fun fact: co-founders of ITA and Kayak were co-workers on the core product team at Interleaf. Paul Graham Worked at Interleaf in the consulting group. We all worked together on a major overhaul of Interleaf publishing software based on embedded Lisp. Interleaf 5 was about 10 years ahead of its time in many ways, and was eventually (mostly) crushed by lower cost competitors FrameMaker and (ugh) M$ Word. Paul brought some Interleafers into Viaweb.
Thanks!, I had not seen the style guide. As someone else said, this probably comes from Google’s purchase of ITA. Common Lisp is stable, well documented, many fine implementations so I find it odd that there are only pockets of developers/companies who use it. Similar situation with Haskell.
It is definitely curious. Whenever I mention Common Lisp is my preferred language people start talking to me as if I'm some wizard from another dimension. That, or stupid parenthesis jokes.
It really has an image problem.
I always try to explain that I like Common Lisp because it is an easy and very practical language, but the people I talk to that have no experience in it think it is very hard and impractical. I think the latter is because of university courses where one is not allowed to use the full power of the language.
Low popularity, meaning it's much more difficult to find employees proficient in it, making it a bad proposition for companies... which keeps it unpopular. The vicious cycle of fashion.
What Java helped was the big pockets of SUN / later Oracle, because it was their language. Initially for small machines, it then helped them to sell lots of hardware into the 'enterprise' running slow (but portable) Java applications.
The Lisp Style Guide actually predates Google's acquisition of ITA. Common Lisp was used to develop some machine learning code. After the acquisition of ITA, the guide was extensively updated.