TallComponents discontinues PDFWebViewer.NET
Posted 02 Oct 2012
Source code now available on CodePlex (here and here)
On the company blog, CEO Frank Rem states that the product is not part of their core technology and revenue is insufficient to justify the load on support that comes from a browser based component.
As the original developer of the product I'm happy with TallComponent's decision to open source the product rather than to keep it locked down and let it die.
Looking at the source code brings back some good memories of building a nice product. I'm also curious to see what has become of it in the past two years.
Looking back
Technology wise it hasn't changed much. The server side was built on TallComponents' excellent flag-ship products PdfKit.NET and PDFRasterizer.NET.
At the time PDFWebViewer.NET was created, ASP.NET MVC was an emerging technology and Microsoft hadn't embraced open source yet. So the client-side implementation was based on the now pretty much obsolete MS Ajax framework.
Though version 2.0 looks like it's been modernized it hasn't really evolved. I'm sure this also accounts for much of the support load that TallComponents must have been experiencing for this product. Especially with HTML5 and mobile devices on the rise, as mentioned on the blog, a full rewrite would probably be in order.
The essence of the product was to use common HTML constructs only to display PDF, a couple of years back that meant using divs and images with plain vanilla javascript.
Looking ahead
Nowadays it would probably be safe to implement the control using a canvas, which would make it much easier to implement a lot of the functionality. For example, rotating a page required a round trip to the server in the original implementation but can be done in the browser when using a canvas.
That would also eliminate a lot of common issues with alignment, scrollbars and the like.
In addition to that, commonly used javascript frameworks (like jQuery) would probably also go a long way in solving cross-browser scripting issues. It should also help reduce maintenance overhead by reducing the amount of code involved in handling events and manipulating the DOM.
Life expectancy
An open source project that relies on commercial components (however good they are) is probably doomed. I’ve been supporting and using software components long enough to know that any component (or open source project for that matter) gets developer attention as long as the project that is using the component is in development. After that some occasional maintenance may trigger a bug report but there’s not going to be any developer love.
Since the product was not sold in large volumes there are probably not a lot of developers actively working with PDFWebViewer.NET. Therefore the most likely scenario is that there will be little, if any, activity on the Codeplex projects.
The life expectancy could be improved if somebody decides to replace the proprietary core components with freely available or open-source counter parts.
Final words
As with any software project I’ve worked on I do hope people will continue to use PDFWebViewer.NET. I’d love to see people forking and contributing but, as Frank has hinted in the blog post, the product wasn’t a big seller so I’m not expecting much.
TallComponents
Thanks for your comments Marnix.
I don't expect the CodePlex projects to take off. They are primarily a safety net for existing PDFWebViewer.NET customers.
As for version 2.0, we did a great deal of code refactoring which did reduce the maintenance load. Apart from that, no fundamental changes were made.
Since 2.0 has been refactored, it should be much easier to replace our commercial products with Open Source components that should be able to provide a rendering service and reading out navigation structures such as links and bookmarks.