[EMAIL PROTECTED] wrote:
> Hi,
>
> If database connectivity was currently available, I believe you would most
> certainly significantly reduce your development effort by using REBOL.
>
> Since you say:
>
> >I have the luxury of waiting for REBOL to develop abit as the data
> >normalization should take a bit longer to do. Any thoughts
>
> you may want to wait.
>
> Remember that REBOL is a programming language, and you do have the option
> of working around the missing database support by:
>
> 1. exporting db records as tab or comma delimited files, or
> 2. using REBOL's port mechanism to interface to a database of your choice.
> 3. Depending on the size of your database, you may even consider using
> REBOL to store and retrieve the records.
>
> re 2. If I'm not mistaken, FoxPro uses a dbf type file structure. If
> FoxPro's file structure is documented, or there are libraries available
> that will access FoxPro's database from a C or C++ program, you can
> probably "roll your own" REBOL-2-FoxPro interface (and publish the code on
> rebol.org ;-).
>
> Or perhaps your employer will sponsor an OpenSource effort to create a
> native FoxPro REBOL interface?
Yes, there are two aproaches available.
1) Do it all with REBOL
- use ports
- wait for /Command, let's bring some open source C/C++ library onboard, build
something - probably better solution, as it is not TCP/IP dependent
2) REBOL as a tool. Wait for /Command Toolkit version, embedd REBOL into your
own apps, create some clever REBOL object in a /Apache object style, extensible
in run-time, and let it interact with outer world ...
What to choose - 1) or 2)? Both ways have their sense. While 1) will gain
popularity to REBOL, open its capabilities to much wider auditorium of
users/programmers, 2) is here mainly for developers, to bring their apps more
usability/connectivity, etc.
-pekr-
> ;- Elan >> [: - )]
