Now MS Project has an XML interface so coding up an IO and mapping component proved trivially easy. However, when it came to talking and sending messages directly to MS Project in order to have it understand and respect the clients user model and business rules - ie. a head of production can edit a production schedule whereas an artist should receive a locked down interface providing only a read only view of data relating to their role - now this became a major problem.
So compound these considerations with the reality of a user base split between Windows, Linux and Apple systems and you begin to understand why I directed our team to port and reverse engineer a subset of MS Project's functionality to the web in order that we could author a solution that would successfully achive the client's desired implementation aims and to realise this in way that would be accessible to all users whilst respecting the clients strict policies of data access, security, disclosure and so on.
For my part what i would like to see is a realisation of COM for the internet age of distributed de-centralised computing. Tony talking about this notion at the outset of the interview when he discussed the transition from mainframe to client-server systems architecures.
Now a few years on, XML works to a point in terms of data interchange between disparate systems but then hey apache's http.conf file does the same as do any number of other arbitrary plain text data structure formats.
As a solutions architect when i cannot dictate the type of platform to be used, for legacy reasons, or whatever, what would be really useful to me is a componentised accesible software model built built around a rich api interface, much as Tony pointed out when he disucssed certain principles that UNIX is based on. I can pipe the output of FIND into SED and i can customise the behaviour of GREP to further distill a result set. Like LEGO - a simple, clearly defined interoperability interface with which i can build rich and complex solutions ot problems based around the combination of existing patterns.
So right now, why can't i instantiate and call remotely via a web HTTP api request say, a temporal date / interval based schedule calculation engine component of an MS Project app in order to for example calculate a projected end date for a task based on a supplied start date and duration interval. And why can't i make a request to a server based installation of Project to have it render back to me a customisable browser friendly gantt activity timeline?
I've just wasted weeks porting some of this functionality first to a set of PHP classes for rapid concept prototyping and then subsequently to a compiled set of Sybase Transact SQL stored procedures (like going back 20 years) in order to deliver a solution that works expediantly, in a way that is computationally efficient and sympathetic with a clients existing technology investment.
Genuinely, I'd like to see the principles of COM and OLE applied in a meaningfull way to a distributed internet based service orrientated software model with a result that actually means more than just a bunch of hyperbole and marketing jargon. Moreover if these components can be actually assembled and translated into solutions that result in real world commercial applications then the more the better.