On 2/4/2011 2:29 PM, [email protected] wrote:
In a message dated 2/4/2011 11:23:36 AM Pacific Standard Time,
[email protected] writes:
Most of this discussion is about client side connectivity. What I would
love to see is a replacement for UniBASIC. Server side language
bindings are what interest me.
Of course you can do this.
Which of your clients do you think would be willing to pay me to develop
all the subroutines in PHP ?
You will never be able to go completely away from UniBASIC while keeping a
U2 database. I don't think that's possible. How do you even address the
database without going through the low-level read write core ? You have to
scan the file structure, with a knowledge of groups and delimiters and link
space and then be able to extract the records, and put them back... by frame.
and append when necessary and relink. That's a lot of code.
But you can certainly create the routines in PHP that do the file
manangement with the UniBASIC relegated to just the middle level of read-write
processing and nothing else, and then start building your PHP routines on *top*
of
these.
W
_______________________________________________
U2-Users mailing list
[email protected]
http://listserver.u2ug.org/mailman/listinfo/u2-users
If I was in Rockets shoes, I would reimplement Unibasic in python, or
maybe a jvm language, like Clojure is LISP for the jvm. All the
existing code would still run, but you would gain all of the goodness of
the last 40 years of work.
Doing as a JVM language is probably the safest move, and wouldnt be that
difficult. Think, interopability between java, scala, jython. It would
really breathe new life into the product.
I think what I would call this is "refactoring" the DML. Leave the
verbs there, but reimplement them.
_______________________________________________
U2-Users mailing list
[email protected]
http://listserver.u2ug.org/mailman/listinfo/u2-users
