On 2/7/2011 3:58 PM, Tony Gravagno wrote:
From: Charles_Shaffer
You will never be able to go completely away from
UniBASIC while keeping a U2 database. I don't think
that's possible.
We use Uniobjects on our web servers to access our
Unidata servers. Technically we could avoid UniBasic
with Uniobjects, although I don't recommend it. It
has makes more sense to push the database logic to the
database server using Unibasic routines called by
Uniobjects.
I'll interject that there are two discussions going on here:
language bindings outside the DBMS, connecting in via whatever
pipes happen to be available (UO, C, Intercall, sockets, etc),
and language bindings built into the DBMS alongside BASIC.
I'll go on a limb and state my belief emphatically that we will
never see another new language implemented within the DBMS
itself. (The only other language I've ever seen built over MV
was RPL (PQN+), which is now only available for D3 with variants
in jBase and Reality). The DBMS vendors have no motivation to
undertake the massive effort of creating a new compiler and
runtime to operate over the DBMS engine. Claims of new sales
potential with mainstream languages can't be substantiated; We
obviously already have external bindings and MV sales have never
spiked because of it.
Now, as I've said recently, we can immediately build our own
external language bindings with no help from any of the DBMS
providers. Unfortunately this option leaves us to connect in via
the above methods, and no matter how fast that happens, it's
subject to a performance hit. A much more elegant solution would
be an API that dynamically links with the DBMS monitor to perform
"direct" read/write/call and other operations. Maybe someone can
tell us if the UO server component really is this "closer to the
metal" interface, but it's always seemed to me that even that
server component is one step and a performance hit away from
direct DBMS access. With such an API (and direct access for file
open/read/write, etc) just about any language can be implemented
"inside the box", again with no help from the DBMS provider(s).
I'm guessing we could count on two hands how many people might
actually be intensely interested in any of this.
T
As an end-user developer, you probably won't find much interest.
There's too much to do with the core business code as it is. Would it
make life easier for the "few" solutions developers who actually might
want it? I know I've wanted similar gut hooks for my own oddball
projects but I have always found a way to make things happen without it.
Just because we're clever enough to connect points A and B, though,
doesn't mean we should simply accept that the steps involved always be
convoluted and the process numbingly inefficient. Do the DBMS vendors
not care about making the solutions-providing developer's lives easier?
Who really sells their product? How many forward-thinking developers
have left MV because these "should-haves" never have existed. How many
migrations have happened due to a small subset of those "must-haves"
have popped up in another flavor?
GlenB
_______________________________________________
U2-Users mailing list
[email protected]
http://listserver.u2ug.org/mailman/listinfo/u2-users
