On Thu, Mar 2, 2000, <[EMAIL PROTECTED]> wrote:
>Having done something similar with ASP and MS-SQL Server 7, using ASP to
>fetch pages to a server, and then using ASP to parse them (by requesting
>the asp page with the file name as the parameter) and spit back a
>success/fail message, and then having Rebol take the appropriate action
>(deleting the file because it was inserted successfully, or emailing the
>admin about a failure, and leaving the file in the queue to be reprocessed
>the next time around)
>
>I can say it works. It's ugly, but it gets the job done. On the other
>hand - what [EMAIL PROTECTED] is trying to accomplish is just better
>done in PHP alone.
First, I've never really said what I'm trying to accomplish. ;) I
just said I'm probably going to need a database.
For instance, one thing I'd like to implement on the site I'm working
on are simple discussion forums. Nothing really fancy, and certainly
nothing that would contain more than a couple of hundred messages. A
MySQL database certainly would do the job, but seems a little like overkill.
But what's the simplest way to serialize modifications to the forum
file/database by Rebol CGI scripts? I've thought about using a temporary
file as a crude sort of semaphore. (Hence, one of the needs for a unique
ID...)
Another possibility might be to make a 'simple' little Rebol server
daemon to serialize or synchronize file/database accesses by CGI scripts.
Still another possibility is to somehow integrate just enough PHP to
cover Rebol/Core's deficiencies.
>Why bother to add another layer on top of it? Just to
>use Rebol? That kind of solution flies in the face of the Rebol
>phillosophy.
>
>K I S S
>
>Keep it Simple, Stupid.
That's what I'm trying to do. I don't think reading a PHP page to get
the time with millisecond resolution is a particularly complex task.
Reading PHP pages to access a database might very well be too hairy to
try. I haven't attempted it yet, so I don't know.
But for the real meat of what I want to do, Rebol's flexible syntax
really seems like a boon, i.e. what I want will probably take a lot more
PHP code to implement than Rebol code.
>The simple solution is usually the best, and most correct one. When
>Rebol/Command comes out, and you can access deeper functionality using
Well, that's what I'm wondering about. I can definitely run
Rebol/Core on the site I'm working on, but I don't know what the
requirements for installing Rebol/Command are and I'm pretty sure my
hosting provider won't install the Rebol/Apache module when it comes out.
Incidentally, does anyone know what new capabilities the Rebol/Apache
module provides? Is it like PHP where you can embed arbitrary chunks of
Rebol code in HTML? Or is it just something that speeds up Rebol CGI
execution?
>Rebol - then will be the time to give it a whirl to provide dynamic web
>pages with a database back-end. Remember, just because you can do
>something doesn't mean you should.
You know, for now, I'd be happy with some simple and robust ways to
synchronize multiple active Rebol CGI processes and a really simple
flat-file database. This sort of thing should be possible in Core.
.:Eric
P.S. Here's a function which should generate a unique hexadecimal ID and
the associated html for the mstime.phtml file. This isn't too funky is it?
unique-id: function []
[ s r text]
[
r: read http://www.smallandmighty.com/mstime.phtml
parse r [thru "<body>" copy text to "</body>"]
text: trim skip text 6
s: to-decimal text
s: s * 100000
s: to-string to-hex to-integer s
return s
]
<HTML>
<HEAD>
</HEAD>
<BODY>
<?
$mtime = microtime();
$mtime = explode(" ",$mtime);
$mtime = $mtime[1] + $mtime[0];
print $mtime;
?>
</BODY>
</HTML>
