David Gewirtz wrote:
John Stanton wrote:
I don't understand how you apply Frontier. To build a multi-threaded web
server
hosting Sqlite looks like a project to replace Frontier, which already has
embedded Sqlite.
Ah, ok, let's back up. I and some other developers finished adding SQLite
into Frontier last month. Before version 10.1a11, Frontier didn't have
embedded SQLite.
So, now that it's in Frontier (like SQLite runs in PHP), it's time to start
building apps in Frontier that use SQLite. So, like you might build a
shopping cart in PHP that uses SQLite to keep track of purchases, you might
build a shopping cart (or, in my case, a content management system) that
uses SQLite to keep track of purchases.
So, now that SQLite's embedded in Frontier, we're learning how to make it
work and what the limitations are. And that's why the questions.
Make sense?
-- David
You confused me when you said you were writing a multi threaded web
server to host Sqlite. I now understand that you are designing
applications to run on an existing web server.
I recently wrote a multi-threaded web application server and compiler
for its own byte coded application language and which we use to host
applications. It buries all the threading and multi-user contentions
within the server program and leaves simple logic at the application
level. The byte coded output from the application language compiler
runs in a virtual machine in the server.
It is yet another PHP-Frontier... application server system, but is
tailored to run our applications optimally. Sqlite is a very good tool
to embed in one's own application server. It fits in with a minimum of
gotchas.
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
