[LON-CAPA-dev] user names, course names, resource names, and passwords
Scott Harrison
lon-capa-dev@mail.lon-capa.org
Sat, 14 Sep 2002 10:44:09 -0400
Hi Guy,
Thank you very much.
> > User names (spaces allowed? dashes allowed? ^L allowed?
> > greater than 2, less than???)
>
> must be \w
> at least 1 character
Already the same (yeah).
>
> > Passwords (you had mentioned 15 characters)
>
> 15 looks like what we trucate at, I don't think there is a restriction
> on which characters are valid. (I have tried many symbols but I
> haven't tried control characters.)
Yes... from the lonnet/lonpublisher code, it looks like every character
is &escape()-ed. So there is no risk of tainting. (Just wanted to
verify.)
> > Course identifiers
>
> Must be unique, and alpha numeric, and contain the name of the
> library server at the end/
I think I remember now... the actual course identifier
is fairly random looking... like LJKOIJ234ljklkj_msul1 or something.
Is there a separator between the uniquifying string and the library
server name?
> I'd suggest when it comes to creation of users/courses/resources to
> continue to use the underlying functions in lonnet/publisher it will
> be very troublesome to reimpleent that code and get it correct.
I do not anticipate a scary crossflowing merger of data. I do anticipate
making it as easy as possible for sysadmins to select to use or not use
various courseware packages underneath the tool I am developing.
And yes, currently, LON-CAPA is the only fully functional solution that, unlike
Blackboard or WebCT, legally allows for adding customized features on top.
And due to its open source nature, it also allows, in a practical sense,
for adding customized features on top. I preach to the choir....
I am, however, doing "scary" R&D things, so it is important
that the APIs and protocols (even simple things like "user names") be
relatively consistent so that there can
be multiple possible points of integration.
Which is a good thing.
Source code diving is fun, but I am trying to be clear on the API and
protocols so as to be non-destructive in both ways.
Regards,
Scott
--
Scott Harrison, sharrison@users.sourceforge.net