Some "API's" just need to die. Consider the one I recently worked with- an abstruse, and seemingly undecipherable pile of slop. This particular API exposed a UNIX-like command line interface for querying a library database. Queries were frequently piped (c.f. SQL JOIN), and almost completely undecipherable without the help of a poorly worded, massive, "manual" (password protected of course).
My specific task was to circumvent the piping functionality for a few commands, which were failing on Windows. The specific API commands were apparently designed for UNIX systems. Piping them on Cygwin was leading to rogue spawned processes. Long story short, it was decided that the piping behaviour be handled manually.
Windows imposes a 8191 character limit on its commands. I couldn't just redirect input as I pleased- input often exceeded this limit. Sending input by chunks proved viable initially, by was an O(N) solution, N being the number of chunks. This scaled poorly for popular library books.
Scrapping that, I made a custom parser for handling the API commands, where only the bare minimum was piped. This was an interesting, but tedious, hack. Without giving too much away, this was the only alternative (to give you a hint of the irritating stuff which led to this decision, consider running primitive API commands in a primitive Gnuwin32 environment, with a whole ton of other medieval restrictions). It was tough going, though worth the extra effort. It ran at O(N), N being the number of piped commands, a significant improvement, most commands being really short.
Even for the most popular library books, our queries ran under 800ms!
What a hellish ride though. I'm sure this will make a good story someday, and by good, I mean I'll probably have to stab somebody after.
No comments:
Post a Comment