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

[Daniel J. Cody]

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


> Well, no, but I don't think that matters.
 

+1

 
>>As the user posts messages, their article counts and references are all
>>correctly updated on the food.evolt.org site.
>>
> 
> I guess I could go with that. But, I'd like to somehow have the
> propogation outside of the evolt CMS code. Especially in the situation of
> a changed password or email address or something like that.


ya, i think anything having to do with a user's info has to come back to 
ueue.evolt.org in terms for <form> posting and shit.. this obviously 
will take a bit of work and jerking around, but again, its better to do 
it now rather than a year or even 3 months and 500 new users from now.


>>course begs the next question:  How can I know how many articles that I've
>>written/commented upon/etc across all of the *.evolt.org sites.
>>
> 
> I'm not sure I see the need for reporting that... unless we were going to
> somehow have a cube-like system for overall community participation. IOW,
> not that big of a deal if it's troublesome.


well, if you write something from food.evolt.org, the backend is in 
place to get your userid, username, etc to insert into the solitary 
food.evolt.org DB. same with articles - you could insert articles on 
food.evolt.org(our best example cus they're so close) without needing to 
query the USERS table of the evolt DB. you just grok the userid, who, 
etc from the cookie and insert that information into your article... or ??

 
>>Global User Information
>>-------------------------
>>If we don't do the one global table, like Matt has already suggested, then
>>any application that wants a 30000 foot view of User specific information
>>will have to query the ueue.evolt.org server for the list of all Child
>>Servers the user is a member, query each Child Server for the user's content
>>information, and pull all of that into one report or list.
>>
> 
> Ok, here's my thinking. When you sign up for www.evolt.org, you should be
> "signed up" for all *.evolt.org sites. So, I don't think the list of sites
> of which that user is a member is needed.


+1 - specific and solitary *.evolt.org information is up to the person 
running *.evolt.org - a food.evolt.org article is distinct and seperate 
from a www.evolt.org article.

we're not shooting for a complete replication of DB's here - we're going 
for a single sign-on for every *.evolt.org site now and in the future.. 
its going to take a good amount of rework for us all, but again, in the 
long run its worth it..


>>Without a 100% central repository of content information, one must
>>replicate.  Dynamic queries over the network will be to expensive. 
>>
> 
> All the oracle databses reside on the same server.


our *base* oracle DB - user information/authentication - is only 
accesable from ueue.evolt.org


>>Besides,
>>the admins of food.evolt.org may not have any interest in showing the other
>>things their users have done.  They may just want to focus on food-related
>>stuff.
>>
> 
> +1


+1 - again, this is a single sign-on thing, not a 'lets share every 
piece of data with every other *.evolt.org site out there thing


>>I'm sure I'm not suggesting anything really new... It sounds like parts of
>>this discussion have happened in the past.. :)  Please forgive me if I'm
>>repeating an existing argument... :)  I'm slowly trying to make my way
>>through the archives... :)
>>
> 
> Yeah. Look for "login.evolt.org". I believe it's even in the subject
> line. It was quite a while back. Dan was working on it (so he'd be the
> author of the messages). Hope that helps some.


ya, mark lemme know when you wanna look at what i've got done already. 
basically, the 'ticketing' is done already on login.evolt.org(a 
prototype i was doing on my own that relied on sessions and not cookies, 
which was the wrong way to go.) in CF. lets get together on IRC tomorrow 
and i'll tweak that CF to use MD5(which i looked into today, and *fuck* 
was that the way to go! nice call :)


.djc.