user profiles

Bryan Dumm bdumm at bobby.bcpub.com
Thu Jan 18 12:53:14 PST 2001


Howdy,

<previous email between Neven and I.>
 
> Yea it took me a bit, but the more I think about it, the kewler the
> user profile becomes.....

<snip>

> make more sense?

Much more sense, and I like it. :)

Maybe we can even allow putting a package names/top level directories in that
user profile, so that the system profile becomes totally independent even
 from packages versions/extensions/whatever?

You should start a discussion on one of the lists about all this, it's really
interesting.

Neven

-------------------------------------------------------

Ok, I don't have the time at the moment to really go into the user 
profile, and I plan on next week sometime to really start to hammer
out the ideas in code. So if you understand this basic idea, got some ideas
etc. please send them in. If someone else wants to get to this before
I do, go ahead, but I'm still going to come mangle your code next week. :)

Anyways, user-profile take one....

The backend has say command A <make dir="&builddir;/package-1.0" /> and 
before the backend runs command A, it runs through hash B %user which is 
really just the user profile in memory... By running through hash B the 
backend finds out that this person really believes in the make sucks 
subroutine cause the <make_sucks level=10> tag was set. Level 10 of the 
make sucks subroutine tells the backend to try every way it knows how to 
make that fscking package. If I didn't care about such things I could 
have it set to <make_sucks level=5> or something

The point being even if <make_sucks> is a bad example is that we have 
"abstracted" away from the backend, it's making of such decisions on it's 
own. Instead we have the user profile do it for us. Logging, Error Handling, 
Automation preferences, hardware, or just anything that is a choice. 
 
the backend logic could be like

sub tag_make {

$make_sucks_level = $user->make_sucks('level');

if ($make_sucks_level eq "1") {
hack it this way
}
else if ($make_sucks_level eq "5") {
hack it this other way
}
else if ($make_sucks_level eq "10") {
beat on it till it gives up
}

other preferences could be say front-end details(like web/qt/console/etc.), or
even how about 

<backends>alfs newone otherone</backends>

This way backends are just there... I am sure the tag would be more like

<backend name="alfs" location="http://somewhere" param1="something"> etc....

and maybe system profiles can have their DTD info, which would help the 
front end determine, ok I got this system profile that uses the "newone" 
backend, and let me look that up in the user profile, oh yes the user does
know about this "backend/DTD" and ok here is the location, sending info
there...... We can also use xml namespaces to prevent clashes between 
backends or things like www.rddl.org which namespaces seem to be moving 
towards..... Heck I believe with namespaces would could even mix multiple
backends in the same system profile. 

<alfs:config>
and
<newone:config>

are two different things...

Does any of this make any sense?





More information about the alfs-discuss mailing list