Forum OpenACS Q&A: I want my, I want my, I want my web/db
Thanks to everyone working to scavenge aD. Let me apologize for not
being able to follow up as I had agreed to, I'm in the middle of some
ugly personal stuff that I need to get through.
That said, with the demise of aD, I mourn the loss of our high signal
to noise ratio web/db forum. I would like to suggest that we create
another forum here, or perhaps formally relax the suggestion,
inherent in the name, that this forum pertain mainly to OpenACS issues.
I want my web/db! (Of course, I'd also like some money for nothin'
and chicks for free.)
How about it?
Actually, that should be clicks for free...
Sorry, it's Monday, and I just couldn't resist.
Importing the old data wouldn't be that hard for someone with time on their hands. Anyone have time on their hands?
That being said, I nominate Todd Gillespie to migrate the web/db and OACS bboard stuff, if for no other reason than he will bitch so eloquently upon learning of his nomination.
Is that content under any kind of license? Do we have to worry about people's usernames and IDs being moved to new ownership without authorization?
OTOH who knows, perhaps RedHat will continue developing acs/java or find it a good home. AFAIK none of RedHat's plans for aD's assets are known.
For our next trick, we'll support Java and Tcl versions with a single code base! Yeah!
<b>I AM MAKING A HORRIBLY BAD JOKE. IGNORE ME</b>
I'd have no problem with our having an "ACS Java Refugee Q & A" forum here, though. How do others feel?
In constrast, offering ACS/Java users a gathering place would be purely a guesture of kindness and goodwill. I most definitely wan't suggesting that OpenACS development encompass Tcl and Java!
It seems to me that we need to think about how to handle imported users. Should all the web/db posters be imported into openacs.org? If so, we need to match web/db posters with existing oACS posters, and then insert all unmatched names. Of course, we don't have email addresses to go with those unmatched names. Or password choices, or... I'm thinking made-up email addresses (since the field is required) and randomized passwords, with extra work for the openacs.org admins if/when/as the posters migrate over to openacs.org and want to have their accounts merged.
Of course, if someone can get the actual SQL data (not just a strip of the site), then an import is easier.
About the poster's identities: wouldn't it be possible to add them as persons (the acs-object with that name), not users? From a short look at the datamodels it seems that nothing should stop us from inserting postings from persons that have no user account. This seems cleaner then generating fake email-adresses IMHO.
And maybe one day there will even be admin pages that allow an administrator to elevate an existing person entry to a user account. This could be of more general interest: imagine a company that stores all it's client contacts as persons in it's OpenACS system, and upon request can create user accounts for their clients by just typing their email address in an admin form. Has anyone done somehting like that already?
Anyway, if a merge is required there is propably not such a big difference between doing it with two user objects or a user and a person object.
We need that functionality. No committment, but that add on might come from us.
Cathy, the last time I had to build something that handled imports like this, we used a 'proxy user' system, where data could be owned by what are essentially shells of users -- the person wasn't registered, and the system could ignore the "user" in many places since it wasn't real, but if that user registered, [s]he would inherit any the data registered in his/her name. Does OpenACS ("oaks") have anything that can be munged into acting like that?
Cathy, would you mind working with me? Or I could just write some db manipulation fxns for you... either way.
Something I brought up on the IRC channel - has anyone looked at the legality? Would lawyers over at RH/aD notice this and take offense whilst they are trying to catalogue their acquired IP? Should we wait?
For example, if someone is not on the OpenACS website, but they are registered on the web/db board, what would happen if I tried to create an account as them? I guess I probably would just get all their postings linked to my new account, right?
I guess that's not as bad as it seems. :)
If that is so, then it's probably time for http://openacs.museatech.net to move over to the OACS server OpenForce purchased. Maybe run it on new.openacs.org or something? It would be more of a task to migrate a site with a large DB twice than just once, no?
1. query patches to the query files, not .tcl files
2. PG as well as Oracle (I don't want to start drifting apart on minor patches, we'll never get the worlds aligned again if we start down that path!)
Todd asked if I'd be willing to work with him: sure, if there's work for us to do!
If I'm reading Michael's post correctly, he has already written some code to do the openacs-web/db import (or at least matched user names to emails, something beyond what was in the downloaded html files) in some way, so perhaps this is done or nearly done already.
I was picturing a script to insert the web/db users into the users table (perhaps as deleted users, but with correct emails?). But Graeme's patch and importing into oacs4 sounds like a better way to go, if the site migration is going to happen soon. I haven't done anything with oacs4, so I won't really be able to help with that.
The advantage to inserting deleted users in 3.x (rather than patching 3.x) is that the new data could be imported to OACS4 right along with the users and bboard data, without additional scripting.
I agree that someone should take this up with aD.
So where do we go from here? Seems like some decision from the gatekeepers as to what tack we take?
Musea took the lead early on but then had to drift off to work for money (boo-hoo for them, eh?) I fixed a bunch of Postgres-related performance problems that makes the site practical to run (though I'd like to speed up bboard even more). But now I'm busy juggling contract work with trying to finalize the OpenACS 4 beta (very close, very close!)
So what really needs to happen is for a couple of folks to step forward and offer to push on.