Yes this is possible, but there are a number of idiosyncrasies with the whole system to watch out for. What I did for my application was to write an ASPX HTTPHandler (the target platform was entirely windows based, but this could be done just the same way with a LAMP stack) that picked up any incoming requests of the format DXFDrawing-###.dxf, where the ### was the database ID of the drawing requested. I wrote the handler to pull the binary drawing data from a field in a SQL database, and return it as the response with MIME type application/dxf.
The reason I created the custom handler as opposed to just slapping the same response into a normal page is because iDrop / autodesk products have a freakout about urls. They will not accept www.blah.com/drawing.dxf?ID=5 or www.blah.com/drawing.aspx even if the response is 100% on the money.
My full setup has three custom HTTPHandlers written: One to generate iDrop XML package files on the fly, one to load and return the proxy images for iDrop objects from the DB on the fly, and one to load and return the actual drawings themselves on the fly. This way all I have to do to display a full iDrop component is have some javascript on the page insert a new set of tags for the iDrop control itself, and point them at iDropPackage-###.xml with the index of the component I want to display.
The setup works pretty well in the ende -- rather surprisingly given its convoluted nature. Now if we could only get Autodesk to deal with this issue: http://www.rec-sec.com/2009/04/30/autodesk-idrop-activex-heap-corruption/
As a side note side: the autodesk products I have tested this on, will completely ignore port specifiers in the forwarded URLs. This means that the iDrop system will not work correctly off of port 80 (this gave me a big headache in testing).
Edited by: dmos on Jul 9, 2009 8:19 PM
