[thesite] voting for articles

[.jeff]

djc,

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> From: Daniel J. Cody
>
> rudy wrote:
>
> > instead, i would still go with the one single user
> > table in the database, and require that it be
> > updated via the site for *all* application uses
> >
> > then copy user data out as frequently as practical,
> > e.g. run an overnight cron (if that's the way to do
> > it) to extract all the subscriptions to the various
> > lists, and overwrite (that's another technical term)
> > all the individual subscription flat files that MG
> > thinks it's maintaining...
>
> problem with that is that theres more information in
> MG's files than in the www.evolt.org DB user tables.
> examples: is a user(djc for example) on the digest
> mode or regular mode for thelist? if the digest mode,
> plain text or multipart/mime? do they get copies of
> their own posts? do they wan't their email address
> hidden when they send messages? are they nomail?
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

no problem.  add database architecture to the oracle database to support
these sorts of features.  tie them to user records.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> theres also the many things specific to logging in to
> the evolt website that MG could really care less about,
> if you know what i'm saying :)
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

those things you simply don't write out to the flat-file database.
basically, for the nightly update, you simply query for the information that
the major is looking for and write out those flat-files accordingly.

i really don't see this being that difficult a thing to implement.

thanks,

.jeff

http://evolt.org/
jeff at members.evolt.org
http://members.evolt.org/jeff/