Technology That Changed Air Travel | Hacker News Reader

Technology That Changed Air Travel

tryretool.com

67 pointsrefrigerator20 comments

Hi! I'm the author of this blog post. This was fun to write: I've taken a bunch of flights in my lifetime, and was always curious what travel agents are doing when they book a flight, or what check-in agents are doing when they "can't find the ticket".

Thanks for the article, interesting read!

In 2016, AUS airport a colleague and I at the gate offered our seats for a later flight and ~$500 cash. The helpful attendant starts "searching" for a possible double-ticket in their system, to my biggest surprise, not really using the mouse but just typing, like "hackers" in movies.

At one point she tells us disappointed she couldn't find anything, and turns the monitor to show it to us. Both working in IT, we look at the screen totally astonished: 80x25, white-on-blue, looks like a hex editor (pairs of letters clustered), and the lady continues to type in commands, with the speed of how people play candy crush nowadays, not how a flight attendant would use a CLI :-D

Since then I know what GDS is and how it looks like

Haha awesome anecdote, the "hacker typing" thing always took me by surprise too!

Just in case, Dilbert's view on the matter:

https://dilbert.com/strip/1995-12-24

Scott Adams’ views should be taken with a grain of salt: http://comicsalliance.com/scott-adam-sexist-mens-rights/

Oww, comeon, it is a simple comic strip, no need to make a case of something the Author wrote once and with which you may (or may not) be in disagreement.

It kills me now going to a gate and the agent is using a GUI. It’s so insanely slow compared to a good, experienced, gate agent using the CLI.

Deskilling has been brutal in the airline industry. Replacing that good, experienced, union-paid gate agent with a outsourcing-thrice-removed permatemp worker has brought costs down considerably. Making the systems easier to use has been crucial in enabling that.

Not as if it matters, but it's actually 64x25 in most GDSes.

Nice. Where did you found the information about the origin of the GDS? Was it difficult? Once I researched a lot and I didn't find too much.

I worked integrating software with GDS systems for some years, and I co-own a travel agency. I also built a tool to help travel agents, it translates some GDS codes to a human-readable format: www.easypnr.com

How did you find the information about how to interpret the black screen? Thank you for writing your article, I bookmarked it.

I have so many thoughts of this industry, and I also a personal theory of why we can't kill the command interface.

Cool article, but the info about the timezones don't make sense. You say SFO/T-7 means SFO is 7 hours behind GMT, and LHR is at GMT¥8 meaning it's 8 hours ahead of SFO.. but if LHR is at GMT and SFO is 7 hours behind GMT, how can LHR be 8 hours ahead of SFO? That doesn't add up, and honestly it made me wonder if you were just making up your own interpretation of the info...

Also, looking up the Tango timezone in maps shows me it's not Pacific Standard Time.

Hi — sorry, looks like I messed up the timezone details. In the case of daylight savings time (https://en.wikipedia.org/wiki/Daylight_saving_time), SFO is 7 hours away from GMT. But LHR is still 8 timezones away from SFO. You're right that it shouldn't read `LHR/GMT`, but `LHR/BST`.

Then the flight date needs to be adjusted too, December 12 is not during DST for both of those locations.

Back in the early 90's, my best friend and I started a software consulting and development company called 'Sabre Systems' here in Australia.

We started getting calls at least 2 to 3 times a week from travel agents all over the world asking for support and information. It took us several weeks to cotton on that there was a worldwide booking system called SABRE, and that these agents were looking up the name on very early versions of Google or Yahoo search engines (or even just Yellow Pages) and finding our company!

I've been in a different industry for 8 years now, but previously I was in the travel / airline industry working on backend booking systems: it was surprising at the time to me how much stuff was still done using things like VT320 terminals.

Interestingly back in ~2008, Amadeus did actually introduce some new XML web APIs for doing things, but they were so badly designed and slow that we ended up still using console terminal text entering / scraping as it was much faster for performing the same tasks (searching for flights, querying them and booking them).

And this terminal text entering / scraping code was pretty complicated as it had to cope with pagination on the terminals, scrolling text fields on the terminals, positioning, etc. Obviously only supported ASCII as well.

Thanks, I enjoyed the read the first time I came across.

I really don't want to come across as an annoying person but please do not submit the same content marketing articles over and over again. This is the 5th time you're submitting this.

When was this written? It talks about XML as a new technology.

Ah sorry for the confusion — NDC is the new technology (https://www.iata.org/whatwedo/airline-distribution/ndc/Pages...), but it's built on XML :)

Can't help but wonder why they didn't pick JSON. :)

I'd say the article isn't entirely accurate. First off, it's not like they all still use EDIFACT today, XML APIs are there for years for all major GDS (Sabre, Amadeus, Travelport products), and there are multiple APIs with different capabilities. And some APIs are actually available via JSON transport. But that doesn't matter that much, really, there are countless reasons why pretty much all of these APIs are fucked up, XML/SOAP with broken WSDLs as a transport is really more like a minor inconvenience compared to everything else that bothers me when thinking about their APIs.

Reply on news.ycombinator.com