> > Tony wrote:
> >> ... the MV market needs to define a consistent web
> >> service / REST API...
Dawn Wolthuis responded:
> > Any clues on how to get any standard that all MV
> > vendors would deploy? I'm thinking this would require
> > third-party software...
Glen responded to Dawn:
> ...
> there has to be an adopted RFC to define how the comm
> happens and gives granular detail that can not be
> misinterpreted by anyone implementing it. Once that is
> done, it's a matter of building wrappers and
> interfaces for all of the popular languages. ... More
> importantly are there more than 3 developers out there
> willing to suit up and then actually spend time
> building a language hook?
Dawn, we don't need the MV DBMS vendors to provide anything,
whether code, consent, approval, or even advocacy. We just need
a RFC, created by us the community, which is a spec to define a
consistent API. Here is an example of a basic interface which
can be implemented in any language:
We define a basic connection through a class called
mvEnvironment.
>From an environment we can derive an mvAccount, synonymous with
mvDatabase. From a databasee with get a mvFile. And from a file
we get a mvItem. In PHP this might look like this, though the
same pattern can be applied to Ruby, Java, Go, F#, ObjectiveC, or
other common or esoteric languages:
$env = new mvEnvironment($connInfo);
$db = $env.Login($myAcccountName);
$file = $db.FileOpen("CUSTOMER");
$rec = $file.Read($ID);
$db.Logout();
$name = $rec["NAME"]; //...
That API is completely DBMS-independent, transport-independent,
and language-independent. Based on the $connInfo, the underlying
code can use Java, a web service, .NET, C++, along with
UniObjects, UOJ, QMClient, MVSP, or any other tools to get into
the target system. The underlying connectivity can be coded by
anyone who has interest, and a variety of such connectors will
allow developers to choose those which are more performant or
better suited to specific needs.
That's the way the rest of the world works, but someone in this
market people keep looking to the MV vendors to not only provide
the API but also the supporting implementation. That's
completely unnecessary. They can help, and they all do, but we
don't need to rely on them for leadership or to create the
various language bindings we need.
For what it's worth, I already have such a project defined called
mvEsperanto, and a PHP binding has been partially coded. I just
haven't had the time to publish or maintain it. With so little
interest (as Glen attests) even for something that most people
can appreciate, it's hard to dedicate time to anything like this
- especially without compensation. (Nod to recent comments on
FOSS.)
T
_______________________________________________
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
