Re: Project updates again

[jim@mercury.laney.edu]

Still looking for documentation help. Any takers? :)

Summer semester starting at laney; bugs in roster-0.7.0.5 found and fixed;
0.7.0.6 is getting there, will release after I add the accounts to the NT 
server and the novell-3 server. Unix accounts added, rosters printed out.
Teachers not emailed yet; bug in email script; working on that.

In recent releases, I OOPized the "user" and "entry" concepts, putting those
into improved use revealed problems. Some problems fixed by adding a new
field to the User abstraction. Problems discovered later will be fixed 
soon after :)

Looked at eduml, my first impression is this form is going to be slow to parse.
However, it will be possible to create a script to import eduml (looking at it
as coming from, say, the district mainframe and as a list of students that are
either current or dropped) and also export the main db in eduml as well.

There should be no codewise problems in either generating or parsing the
files. Other than parsing being potentially slow, there seems to be no
particular performance problems.

I will pass a description of eduml to the district mainframe programmer; she
might be interested in exporting in this form or at least housing translators.

Our CIS dept has a new dept head, at least for this semester; he is currently
the best CS teacher we have as well. I told him about roster and that I am
releasing it. I let him know that one of the advantages of releasing it is
that as it comes into use, there will be whole other entities using it who
can potentially assist others also using it.

Looked at k12admin... NICE work! 

Note some differences: roster will never EVER directly manipulate
server login databases! (well, not unless someone writes a ServerType
which does... I absolutely recommend against doing so if you want your
servers to remain stable...) The idea I had was: (1) you can add
accounts to as many named servers as you want, (2) they can be any
kind supported, (3) it should be easy for a perl programmer to add
support for new kinds of servers, and (4) the server type object in
Roster should create a file to be read by the tools on that server to
add, delete or otherwise modify the accounts.

Another: I have a small script (which anyone can get, cut up, use,
paste, redistribute under GPL, etc) that builds a list of free unix
IDs on a linux/unix server box within a particular range.  So, there
is no need to worry about accounts that might get deleted. And!  This
means you can delete the accounts without removing the home dirs and
add them back again without losing anything. (look in functions.perl)

Still trying to decide on an overall infrastructure for handling
exceptional conditions and error conditions. I think this can be
created and retrofitted if done right.

Now it's my turn to ask for a status report: is anyone trying to get 
Roster to work? Anyone who is can help me document by telling me what
problems they're having.

-Jim