Hacker News Reader

Comment by _448 | Hacker News Reader

> the future was kludging together fungible objects in Java or .NET.

And, DCOM and CORBA :)

As a web developer in the open source, PHP (YUCK) environment, the single time DCOM has been useful for me was an insurance company who had a government-mandated PDF document they had to send to customers.

Could we just generate a document in plaintext? No. It had to be pixel perfect dummy. And PDF!

Could we just recreate a pixel-perfect HTML to PDF template? No. That would take weeks and the client only budgeted a few hours.

So I asked, how do they do it currently. And they sent over a mail-merge MS Word template. We said, hey, so, we use PHP, open source, Linux. TOO MANY WORDS WE'RE PAYING YOU TO MAKE IT WORK.

Could we use the template in an open source framework compatible with the PHP solution we'd built? Yeahhhhhhhh... but no. The open source framework mangled the fonts, layout, and the PDF rendering was bodgy to say the least.

And yes, we went back and asked really, trully, honestly, does the government really give a shit if this document is not formatted exactly the same as whatever law they apparently passed said it had to look like.

No dice.

So we could have used any language I guess, but we were familiar with PHP. PHP has a DCOM extension that only works on Windows. So I spooled up a Windows Server instance (firewalled within the DC of course) and installed XAMPP and did a bunch of config to ensure it stayed updated automatically and rebooted every night at 1am. A small PHP script on the Windows server provided an API the website could call at any time. The Windows PHP endpoint had an unzipped DOCX, the script would copy the folder, search-and-replace based on API inputs, zip it up as a new DOCX file, opened in Word with DCOM to save as a PDF which was then streamed back into the website's logic all in the same POST request that a client submitted.

It was a kludge, I could think of other ways to do it today, but at the arse-end of a project with an apparent doomsday requirement suddenly dropped in the mix, in the end it took about three days to implement when at the time we were facing a crisis.

So yeah, give DCOM some flak I guess because it failed to launch but it saved one small project for one small insurance company.

Edit to add: That solution ran for years without issue until the company merged with a larger healthcare provider.

FWIW, you seem to be talking about regular local COM and not DCOM. DCOM is COM-over-the-network, where you can create an object on another machine remotely and interact with it as if it were a local object. You are describing just using a local COM object on that Windows server. Unlike DCOM, COM is extremely popular and widely used.

> DCOM is COM-over-the-network

The hint is in the name: "Distributed COM" i.e. DCOM :)

> Unlike DCOM, COM is extremely popular and widely used.

My understanding was that DCOM is nothing but data marshaling and registring GUIDs with Windows registry so that the COM object can be created locally/remotely. If COM is widely in use, then DCOM should be as well. The whole gaming(DirectX) and finance(OLE) industry is built on the DCOM/COM infrastructure :)

> If COM is widely in use, then DCOM should be as well

I'm not sure what you mean. If you don't actually activate an object on another machine, you're not using DCOM. You're just using regular COM. The distinction is pretty clear; if you need the "Remote Activation" permission on a target machine, then you're using DCOM. Nobody is, for instance, instantiating DirectX objects over the network. It may help to know that COM predates DCOM by several years; they are not the same thing. DCOM adds additional infrastructure to allow it to happen over a network.

The distinction here is relevant because DCOM, not just local COM, is the competitor to CORBA. The "distributed" part is the part that didn't work out and that, it turns out, not very many people want.

Good point, it was a long while ago and I was definitely using COM objects. The network interface was handled by Apache with PHP scripting. I stand corrected, thanks :)

I’m curious what you would do differently. Maybe the docx part could be a little more robust, but it doesn’t sound too bad as a way to meet those really specific requirements.

Yeah, I'd do it exactly like he described. Clean? No. Who cares? No one.

Thank you for sharing this story. I consider war stories of this caliber to be unironically heroic exercises of thought.

Thanks, I took a lot of flak from my colleagues and it was always treated like this wart on the outskirts of our COE. The only other options required discarding two month's work and refunding the client, or investing another few weeks building a bespoke PDF generator for this one use-case. I never really saw it as a heroic exercise, just had to think of a way to save everyone's time, money, and reputation in the fastest, safest, most reliable way possible.

I never got a compliment for the solution (just a "okay if you think we can make it work go ahead", and afterwards a "nice work, let's hope it doesn't break") so this is a first. Thanks again.

Reply on news.ycombinator.com