🚀 go-pugleaf

Hans Galema <notused@notused.nl> wrote:
>
>> The user could always change the file attributes and then modify
>> the data.
>
> Of course. But what does that matter ? I thought you were
> speaking of your programs. Your programs will only change
> the live db.

To be more accurate, it will make changes to the db that server
thinks is the live db *if* the client is connected to the
server.

> You make a backup: of course in a different directory! And
> set the whole backup to read-only. Your clients can only
> browse then. Then you are done.

Well not really because to do it that way, the server side
would have to maintain different paths for each user and then
how would the user get the server to browse for them?

>If the user intentionally chnges the fileattributes. Then the user
>is responsable for damage. Not your program.
>
>> If I disallow modifications in code, the user can only
>> corrupt the data file ... 
>
>Heh ? I can not follow that scenario.

Then they would not be able to use my program ... they'd have
to use say NotePad which would almost certainly result in a
corrupted file.

>The administrator will do that. What you can say however is:
>only use ports above 1024.
>
>> Certainly one should be performing error checking but the
>> administrator should also know what they're doing.
>
>I have know idea what was in your mind here.

Vlad pointed me to a win32 API that allows one to first check
if the specified port is in used and I would expect that my
server would need exclusive access to it's port.

> In your other post you said that you backup in the same
> directory. That looks like bad design for me.

If that's what the user does ... what are you to do?

>> I thought this would be common [...]

>That is great. Especially if you can rollback to specific dates
>and times. But then you would need a backup for every specific date
>and time or a transaction logfile which you could play back.

Everything is transaction driven. New transactions that have
been entered into the computer but not yet applied to the db
are kept in 'new' transaction files. For example, for the
General Ledger, that file name might look like April2005.gln

Once the transaction has been applied, it's moved to a
'processed' file: April2005.glp and when the accounting period
is closed, it's moved to a historical file: 2005.glh.

>If you have all these nice things then I just can't believe
>that you don't make archives outside the db directory and just
>set them to read-only.

I noted above the problem that I have with using my server to
access multiple db's at the same time. Do you have a better
idea?

~ JD