September 2, 2011

New Perforce APIs Power Platform Play, Part II

Version Control

Since CEO Christopher Seiwald’s June 2011 keynote describing Perforce’s plans for “version everything” and Perforce as a platform, there’s been a flurry of activity to align development efforts with the vision. I spoke with Alan Teague, technical director and architect for Perforce as a platform, about the cornucopia of APIs his team is building, from the currently available P4Java, to P4API.NET, going beta soon with the 11.1 products, plus others slated for 2012 such as P4WSP, Perforce Web Services Platform. Read part I of the interview here.

Q: Have you heard much buzz thus far about them?

A: In terms of the APIs, we would love to get more feedback from customers and developers. Would they like to see a visual component API? We’d love to see them take all the different pieces of P4V apart and put them back together for their specific environment, or experiment with P4JsApi and provide some kind of new, rich visual experience.

Q: What role does the ecosystem play in all this?

A: Usually, the developers integrating with Perforce are self-sufficient. We would like to hear more from them – that’s what the ecosystem is all about. The thing is, versioning, keeping track of content, is not a narrow thing. We’re moving beyond that, looking at versioning content that isn’t just code – things like legal documents or movies. And a lot of what we’re working on now – the Commons, the Javascript API, the web services API -- are geared more toward people who aren’t developers. We are expanding what we’re doing, engaging with graphic design companies, for example, and learning how to reach these types of people.

The ecosystem is critical to us expanding Perforce-as-a-platform. It’s where you find tutorials, information and documentation. But not only that, it used to be that the APIs were on the related software page of our site. With the launch of the ecosystem, they will be front and center. As part of that, many of these APIs will actually be released in source form (most of these are already available in source form). We want to remove any barrier we can for people who want to build on top of Perforce.

Q: What do you think Windows developers will do with an easier way to hook into Perforce capabilities?

A: The is going beta soon and we’re hoping to see a new Office plug-in built on top of it. We have a Perforce for Office (P4Ofc) product already.

Windows developers are a significant percentage of the developer population. There is currently a Perforce .NET API produced by a third party. We spoke with the person who built it, and he recommended we build a new one from scratch to take advantage of new technology, so we did. Now we have a .NET API that’s actually high-performing, based on modern, .NET Microsoft technology.

We build the APIs hoping they will come. Our general philosophy is try to remove any barrier. One of the barriers is that writing in C++ is difficult. With this API, you can integrate with Perforce in whatever .NET language you are using.

Q: How do you compare Perforce’s efforts in platform-building to those of other software vendors?

A: We’re in the very beginning stages with version everything. We are branching out way beyond source code. Do we know what that’s all about? I don’t think so; we’re exploring areas that other people haven’t done yet. We’re reaching out past the tool developers to those people building applications that use version everything as an underlying component. It’s a process of discovery.