gnuherds-app-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: DB vs FS, cookies vs http authentication


From: Antenore Gatta
Subject: Re: DB vs FS, cookies vs http authentication
Date: Thu, 8 May 2008 17:17:09 +0200

Hey guys, correct me if I'm wrong, you are both right, but you are speaking about two completely different platforms.

Both they work and both, if well implemented, they work well.

The question is if we want to move to web 2.0 technologies or not.

IMHO we should think about that possibility but in a second (third actually) phase and to think well how to do it.

The advantages of using the web 2.0 recommendations are several, but to just think it out and put em in place without a good plane is out of mind.

I strongly advice to keep the actual architecture, that works, and improve it maybe adding some web 2.0 features time by time (feeds, syndications, export in RSS, atom, and so forth), playing with them and in the mean while think about a future new version.

On Thu, May 8, 2008 at 4:32 PM, Dion Rasmussen <address@hidden> wrote:
Hello again,

The relational nature of job offers aren't more complex than that allowed by a standard file-system and duplication of identification numbers aren't much different from that of PostgresSQL. Many file-systems even have automatically generated time-stamps as pr. default properties.

As another plus, by using files for user input, job-offers could easily be distributed over nfs, ftp or via rsync or even http by linking job-offer-files to some syndication directory.

Job-advertisers could have their own advertiser directories with a .htaccess relation to easily enable band-width limit in case of flooding and level of encryption and user access relations.

Offers could then be auto-linked to some public www-data directory relation instantly or at some specific time every day, twice a day via cron, so spam and irrelevant offers could be censored before they're auto-added.

Regards


On Wed, May 7, 2008 at 8:26 PM, Davi Leal <address@hidden> wrote:
Dion Rasmussen wrote:
> Each offer can be stored (dynamically) as a file and shown off (dynamically
> eventually cached statically) with a HTML template using the standard
> file-system as the database-engine instead of some special database.

If a user stores 2 or 3 job offers as files, each file will keep her personal
information duplicated.

That duplication is raised by the relational nature of the information the
webapp work with. The offer information is related with the personal
information of who publish it.

IMHO a relational database as PostgreSQL is the best way to manage such
relational information.

Duplication is a nightmare for maintenance.


Anyway, this project could use a database to keep the information and files
only for cache purposes.

Designing a file based cache system is independent of using or not a database
based design.  However, note a cache system is not needed. The host
gnuherds.org is using has all the information loaded in memory!  There is not
best cache than memory.


> Furthermore the standard HTTP authentication can be used with eventual
> secure socket layer constraints instead of relying on cookies for security.

There are several HTTP authentication methods. What specific one do you think
the project should use?


> Sometimes special databases can be useful but it's a bit easier and a
> better finish to just use the standard file-system for varying data as well
> as static data, for the sake of data-management-ease as well as security
> layout.

IMHO to keep relational information a relational database engine is the only
sane way to go, as exposed above. Duplication is a nightmare for maintenance.

> And once again, a database transaction specification is as complex as
> locking a file :)

Yes, the complexity of its API is similar, but just locking a file will not
work for us.  When you lock a file for writing anybody more can write to it!

When you open a database transaction to write on PostgresSQL another user can
open her own transaction to write too.  Several transactions can be writing
at the same time in the PostgreSQL engine.

We need to support more than one user working at the same time. That is to
say, we need concurrency support.

Besides, the relational nature of the information is too against the file
system based storage idea.


_______________________________________________
GnuHerds-app-dev mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/gnuherds-app-dev



reply via email to

[Prev in Thread] Current Thread [Next in Thread]