[REBOL] Antwort: Command question Re:(3)
From: petr:krenzelok:trz:cz at: 4-Oct-2000 14:13
> > Core to support at least 1 free DB, or create one yourselves! I
> Elan's book < www.reboltech.com > includes a DBMS written entirely in
> People have also mentioned connnecting to MySQL via /COMMAND and ODBC,
> but that just seems like such a kludge.
> Another interesting idea has been to connect to MySQL via TCP. No one
> wanted to work on that before because of /COMMAND. But now that it
> seems /COMMAND will add a licensing fee to every application
> distributed using it, people might be more interested in alternatives
What's more - with /Command and existing web servers (e.g. Apache) you are
left with CGI, while others have free PHP solution integrated as Apache
module ... make your conclusion yourself :-)
However - we have /Core based Apache module, so I think TCP/IP solution
has its place here. I just haven't checked it out yet. But - the only one
real solution to me seems real rebol componentisation, e.g. having per
component pricing, allowing me to get REBOL/Apache for free (if it will be
free) and let's say buy /Library component for it, as Jeff implemented
MySQL library wrapper. What's more - I would even pay for such wrapper.
But currently there is no way how to combine above factors ...
That was the first layer of the problem - the second one is imho
serverless dbms system for rebol/core. With all Oracle, DB2, MySQL you are
supposing the system is running strong SQL server solution. But that's not
always the case. So Elan showed us the way with his DBMS system.
What I would be interested in is XBase (.dbf) solution - it doesn't
require server, but rebol script driver would be probably slow ...
Maybe we could also agree upon some standard plug-ins system, as proposed
by Andrew Martin on rebmail list, and then Elan's or other solution would
be just one of plug-ins ...
the activation/deactivation of plug-in would be decided upon presence of
file in /plug-ins directory, and deactivation just means moving
appropriate .cfg file into /inactive subdir ...
plug-ins are scripts, probably should function as separate modules (once
modules are introduced to rebol), should represent certain domain specific
So far Andrew calls plug-ins components, but it should change imho as
rebol uses 'component name for /View, /Shell, /Library etc. components.
... all is opened yet - we don't have modules yet, we don't have final VID
yet, and so I am just curious, if using 'stylize aproach will be powerfull
enough to handle more complex gui areas (components, widgets), as menu is
PS: sorry for slight off-topic comment ... :-)
> The industry is very much in a try-before-you-buy mode right now, and
> I'm not sure how trial versions would work with /COMMAND's licensing
me too ...