Hi:
>By the way, Tim mentioned ODBC access to his database C/Mix (?).
>Well, the c++ source is going to have access to odbc dlls and stuff that
>Rebol/Core and /View will not be able to do. And command will probably
>have ODBC built right in, so ...
Must correct this..... This is NOT an ODBC DBMS, but I have written
an interface to ODBC already. It essentially leverages MS-Access.
>Also, people are recommending re-writing the database code in Rebol,
Actually, that is my call. And it is so that I can take data from
a (for instance) MS-Access environment and put it in a format
that can be read by rebol on any platform that rebol might run on.
That will mean that a client of mine can use their data on any server
that rebol is installable on. I believe that this can be done
easier and cheaper than with C.
>which is fine I suppose. One might want to choose new datastructures
>which are best for rebol, but if his goal is file-format compatibility, then
>he will not be free to change the data structures on disk, which may
>make certain Rebol optimizations impossible.
Whatever works. Works!
>If Tim just wants to make a single-user database that his web-app uses
>to store data for itself, then he probably could implement something
>decent that works without having to port the entire functionality of this
>commercial product which is probably loaded with extra stuff he doesn't need.
It's pretty bare-bones really. Accomodations can be (and have been)
made to do complex transactions on the publisher's desktop.
This is really for queries and simpler transactions and the server end.
It would be great to connect rebol to MySql, but then I don't know
if MySql runs on as many platform as does rebol/core
>For most purposes, you can get away with a minimal system employing
>fixed-length records and an index of some kind for speed.
>Given that, you can do most basic things you would need. Even writing a
little
>db engine that did that much would take you a while, but it would be a lot
>easier than porting hundreds or thousands of pages of c-code.
And a good choice for that would be dBaseIII.
>Concerning the copyright of the commercial c-code,
>As far as I know, even if it is a translation to another language, the
copyright
>of the original is maintained. This is certainly true of books. If you
>translate
>The Little Prince to Cherokee or some other language, the original author's
>copyright still exists and you won't be able to sell and distribute the
>translated
>version without permission. Your work as a translator is itself still
>protected, too,
>I suppose, but that doesn't negate the rights of the original author.
I'm discussing that with Mix as we speak....
Copyright law and computers is evolving, and in my business - comparisons
legally to human languages (or as in the case of "My Sweet Lord", music),
don't really hold up.
It's really kind of moot, as only in the design stage would the kernel code
be used as a template, the bottom
line is that I make rebol read from and write to database what I
might be working with in C/C++ or Python.
>So, if you decide to make your own db engine, what features do you
>absolutely have to support? Remember each one is going to cost you!
Having to adapt to a different search engine can also cost (and has
cost me) big time!
I've gone from using the big names to rolling my own...
