Common language binding for MV interfaces

A recent U2 forum discussion brought up yet another topic that’s been close to my heart for a long time. The original inquiry was for an interface from PHP to Universe. Many people have excellent suggestions. The topic gradually starts to include Perl and Java. But there is a bigger picture here.

Brian Leach suggested using NuSOAP which facilitates using PHP as a webservice client or server. Once again, "Right On, Brian!" He’s proposing a discoupling of the client from the server. If you do it like this then PHP doesn’t need to speak directly to U2. You can have a U2 (really Pick-style) client-side interface that talks to any back-end. A NuSOAP webservice client call can be embedded as the transport inside a PHP class that exposes methods to client code, and on the server a similar routine can break out the requests and execute them. With this topology I dare say it would be a weekend project to get any LAMP website interfacing with a U2 server on any DBMS.

The thing that seems to be missing from all of these discussions about language bindings to U2 (and other MV platforms in their respective forums) is the definition of a single API to which everyone can code. Without this, everyone re-invents the wheel with method names like CallProg, Exec, RunRule, or Read, U2ReadRecord, MvItemRead, etc. No one will be completely happy with whatever API is devised but without a starting definition we go for years with no bindings. Creating a spec to which others can code is the first step to getting bindings for all languages. This has been proven with other successful projects. As a simple example, look at all of the bindings that have been built around the popular cURL utility and the libcurl library.

I think one candidate for this API is the most recent spec from IBM, the UO / UO.NET API. It’s familiar to U2 developers and it would probably be accepted quickly. But this does nothing for people who don’t use Universe or Unidata. I personally don’t like DBMS-specific API definitions like U2Connection, D3File, jItem, or whatever the DBMS companies want to throw at us. It’s not forward thinking. Wouldn’t it be nice to get people to code to your API even if they don’t have your software yet? That will make it easier for them to do so if you can compel them to migrate for other good reasons.

So another candidate I’d propose is the mv.NET API. It is not U2-specific or specific to any other platform. Code written to this API works on all MV platforms. This facilitates platform interaction and answers the question "how do I get data from X to Y". For those of us who support multiple platforms, we only need to write one client module for all MV platfoms. The .NET interface is already done obviously and can serve as a baseline, but there’s nothing to stop people from writing a new open source .NET interface to the same spec. Ladies and gentlemen, if you understand this, then you now also have a complete understanding of the Mono project which is an independent Open Source implementation of the spec that Microsoft used to create the .NET Framework. Anyway, as discussed above, migration issues are reduced with a common API – which is important for anyone who has tried to move communications code between DBMS X to/from U2.

This all does NOT mean a purchase of mv.NET or using .NET at all!! I’m suggesting that perhaps we can just agree that an mvAccount represents a reference to an account, as well as mvFile, mvItem, etc. This will allow us to create code Java, Perl, PHP, C++, etc, that looks familiar to everyone, no matter what MVDBMS or OS they use for development or deployment. I don’t care where we start, but let’s start with a base on which people can build rather than every attempt being an individual endeavor that may later be forgotten by all – until the next time that someone asks the same question.

So where does this lead?
1) A group should come to some agreement on a base API.
2) A skeleton, or token committee of sorts should be created for various language bindings.
3) Each group codes to the spec created in step 1. No new methods or any other class members get created at the project level, everything must be taken through the API committee.

This gives people who support Java, .NET, PHP, Perl, Ruby, JavaScript, VBA and every other language a place to start. We’ll all know what’s been implemented or not, and anyone starting work on a project doesn’t need to think of some new way to solve a problem that’s already been defined and implemented by others. What do you think?

Comments are of course welcome here, but I request that anything more than a short note should be taken to the Nebula R&D forum which is a better medium for threaded discussion.