What _really_ sucks is one-off fixed-width formats that aren't well defined, or that change suddenly (oh, you thought that field would always be populated? lol no.)

Depending on the business-application, fixed-width formats are fantastic because they allow for genuine O(1) random-access to records without needing to precompute an index first. Writing parsers for fixed-width formats is also much simpler, for example, because it eliminates ambiguity around null-terminators vs length-prefix in text/string/array data - for resource-constrained environments it's great because you can guarantee you won't need to dynamically-allocate buffers. I feel the only real arguments against fixed-width records are concerned with wasted space - which are mitigated if your system lets you compress them somehow - because they'll typically compress very, very well.

Sometimes, fields can turn out to be too short. I have received a few letters from business with my last name truncated, because somebody way back when decided eight or nine characters are definitely enough for a surname.

I have no idea why it is and why people are so resistant to adopting ACKs.

But on the other hand, it's a complicated architectural decision. US military wants absolutely reliable communications? They invent TCP which relies a lot on acks. Swedish telecom company wants fast and absolutely reliable communicating systems? Cue throw hands in air with a "there's no guarantees even with socks so better to simply never assume your message arrived and instead focus on detecting anomalous behaviour." They invent Erlang where there are no acks for messages.

Have we gotten to the point where anything not HTTP is considered old?

But yes, anything but HTTP is "old". In large part because of corporate firewall rules that block anything but HTTP traffic (and more often than not filter even that traffic).

Sounds like they didn't need much if any of what you did. They wanted X and you gave them Y. Y would require them to change the way they worked. Did they need query capability? Seems like they didn't and SFTP would have suited them better.

Honestly sounds to me like you went for an overly complex solution where something simple would have done just fine.

Frankly once they hear it's node.js the users should be bowing down to worship!!!!

You:

a) think about the scope of the problem and what you are trying to achive - you are blocking reads of the files by the uid/gid of the server. It is a known and solved problem. The tool is called chmod

b) think about the surface area of the attack - it should only be the SFTP server. We have ones that are very well known. I recommend the one that comes with OpenSSH but there are others.

c) think about business requirements - user's provisioning etc. That has been a solved problem for years - for the super-complex cases LDAP is used. For the simpler ones you can use PAM.

After thinking about that you just write the needed glue.

This attitude will not serve you well. There's saying no, and then there's getting more information (requirements!?!) to then guide people to better decisions.

But code that does not have upstream development and support is dead code. A piece of code in production is like an Internet connection or electrical or water hookup – it must be, so to speak, “connected” upstream to whoever is providing continuous upgrades and security/bug fixes. Otherwise, it is (to continue stretching the analogy) like a mystery battery or water barrel – it could go bad in many ways at any time and you wouldn’t know it until your equipment starts to fail because of low voltage or voltage spikes, or you start to die of legionnaires’ disease. And unlike a battery or water, there are only cursory, no good and thorough, ways to test their quality, and no way to test their age as measured by the way they interact with the ever-changing outside world.