🚀 go-pugleaf

Hans Galema <dontusethis@dontusethis.nl> wrote:
>
>> All I want to do (at this point)
>> is prevent multiple clients from writing to the database at
>> the same time 
>
>Suddenly there is a database.

I didn't consider it relevent (yet) to the basic design of the
server ... but what do I know ... (?)

> Why would you prevent access at the same timet ?

Only prevent writing at the same time. It's a relational db of
my own design that's super fast and has an extreemly small
foot print and there's nothing (additional) to install or
licence ect..

>I do not grab this. Clients would not read/write from/to a database
>I would think, only your server.

That's how it *will* work in the future. The application was
developed as a stand alone and as such, all of the code
resides in what will be the client. The demand dictates that
the first priority is to get it working on a networked system
for multiple users the fastest way possible.

> How do you want to set up all this ?

    Ask server for permission to write
    Wait for permission
    Tell the server it's finished writing
    Server tells other clients the data has changed

>> (which I know I don't *need* a server for)
>
>Would you really let the clients of your server also connect to
>a databaseserver ?

The server will eventually become a database server of sorts.
The database is just a collection of regular files and as
such, I need some way to regulate writing to them. I could
just use an API to lock the files but a server will have to be
used in the future no matter what and since I want (need) to
make the other clients aware that the db has changed, a server
is better than monitoring the folder because the server can
tell the client exactly what information changed. That way the
client can determine if they are using stale information and
if they need to refresh their view of the db.

For example, if one client lowers a customers credit limit and
another client is in the process of taking an order for that
same customer, that client needs to know to refresh that
customers data.

I thought that I could handle this with a basic message with
params that indicate which file (table) and record (key) were
changed.

>> There are other design considerations like distributed
>> processing
>
>Please explain.

Doing just what you have suggested: having only the server
read and write to the db.

>> and dial-up/web-based access but they're for
>> the future.

>You can have webbased acces if your cgi application
>behaves like a client.

It will - by time we get to the dial-up.

~ JD