[thesite] My Intro and a look at a UEUE Proposal

Joshua Olson joshua at alphashop.com
Tue Oct 16 07:38:10 CDT 2001


Hey guys,

Sorry about missing CodeFest... I really wanted to participate in some form
or fashion.  But, duty called.

----- Original Message -----
From: "Daniel J. Cody" <djc at starkmedia.com>
Subject: Re: [thesite] My Intro and a look at a UEUE Proposal


: Warden, Matt wrote:
:
: > I guess I'm not seeing how this can be done without the possibility of
: > conflicting userids.
: >
: > Well, i guess all new userids would now be generated by ueue, so that's
: > not an issue, right?
:
: exactly.. the prob is we have to do some shit to get stuff *backwards*
: compatible. in the long run though, its easier to do it *now* than a
: year from now when we reallllllly need to do this

Not to be a big pain in the butt, but backwards compatibility may not always
be attainable if progress is to occur (ask Microsoft about there problems
with this).  In order to make this thing work, it may turn out that the
current system may need to be replaced rather than augmented.

A couple of factors are turn-offs for system replacement:

- must decide how much gets totally revised (just the user_id/login stuff,
conjoining of article db's, etc)

- can be time consuming to replace every instance of the old system with the
new

- how can we create a new architecture without destroying the old in the
process

- how long does it take to shut down the old and do the swap when we're
ready

I know this is not a popular view amongst some people here, but I just want
to know other people's thoughts.  Does anyone think a redo *might* be down
the road?

What sort of hang-ups might be present if we retrofit the system with
changes if we stay with the current distributed db model?

What other distributed models may be appropriate?  A model where the user
authentication information is in its own db, forcing authentication into a
black box (since you cannot do cross-db joins) may be one suggestion.

 From there we may even tie the site specific user information into this
black box using some user-site-attribute-value relationship.  The
information is returned from some black-box object that handles
authentication AND user management.

What problems does this create?
1) a black box would have to be written for each engine -- CF, PHP, etc --
that is powering a *.evolt.org site so that the user information can
successfully be stuffed into session variables. This would suck if we didn't
get it right the first time since any changes would have to be propagated to
each code base.
2) The CMS systems cannot JOIN with the user table.  This is where we would
have to introduce some fancy stored procedures to cross the db threshold,
return temp tables, etc.  This could get messy.

Just brainstorming... talk to you guys later.

-joshua





More information about the thesite mailing list