This has been brought up before via e-mail, but I thought I would mention it again here and find some general thoughts/ideas.
Currently, every eledge course to which one goes requires logging in again. (ie, if one were to visit 4 differnt eledge courses, even being logged into one would require logging in 3 more times). This can be annoying, to say the least.
Furthermore, in many environments, it may be necessary to integrate Eledge with some other system, be it a Course Management System, or a school/campus management system, or something different. Such other systems will, of course, have a variety of different authentication methodology, ranging from LDAP backed to an in-house solution.
While eledge -is- open source, and -does- allow for any user to modify eledge according to their needs, such modifications can make keeping current with eledge a difficult task. It also hinders contribution back to the project when modifications made suit only one particular user.
As an example, recently, it has fallen to me where I work to modify the eledge authentication system in such a way as to integrate it with existing components of the institution. While I did, indeed, do this, and while the changes that I made to existing Eledge servlets were fairly minimal, It still becomes a difficult task to commit relevent code while insuring that "site specific" code be left out. Therefore, I propose that we find some means of facilitating alternative login options.
One possibility might be to provide an authentication inteface, rather than an actual class. Then, in managing a course, an instructor could select either "default" eledge authentication methods, or "custom". In the code, arround the authentication area, there might be something like:
if (authenticationMethod.equals("Custom"))
Authenticate.someMethod();
else
//normal eledge authentication procedure
This would allow end users to develop the Authentication interface however they please to suit individual needs, while reducing the need to constantly remove/add code in existing files to keep up with eledge development, etc.
The above is just one idea... any other ideas are, of course, welcome.
Robert
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This has been brought up before via e-mail, but I thought I would mention it again here and find some general thoughts/ideas.
Currently, every eledge course to which one goes requires logging in again. (ie, if one were to visit 4 differnt eledge courses, even being logged into one would require logging in 3 more times). This can be annoying, to say the least.
Furthermore, in many environments, it may be necessary to integrate Eledge with some other system, be it a Course Management System, or a school/campus management system, or something different. Such other systems will, of course, have a variety of different authentication methodology, ranging from LDAP backed to an in-house solution.
While eledge -is- open source, and -does- allow for any user to modify eledge according to their needs, such modifications can make keeping current with eledge a difficult task. It also hinders contribution back to the project when modifications made suit only one particular user.
As an example, recently, it has fallen to me where I work to modify the eledge authentication system in such a way as to integrate it with existing components of the institution. While I did, indeed, do this, and while the changes that I made to existing Eledge servlets were fairly minimal, It still becomes a difficult task to commit relevent code while insuring that "site specific" code be left out. Therefore, I propose that we find some means of facilitating alternative login options.
One possibility might be to provide an authentication inteface, rather than an actual class. Then, in managing a course, an instructor could select either "default" eledge authentication methods, or "custom". In the code, arround the authentication area, there might be something like:
if (authenticationMethod.equals("Custom"))
Authenticate.someMethod();
else
//normal eledge authentication procedure
This would allow end users to develop the Authentication interface however they please to suit individual needs, while reducing the need to constantly remove/add code in existing files to keep up with eledge development, etc.
The above is just one idea... any other ideas are, of course, welcome.
Robert