[LON-CAPA-cvs] cvs: modules /gerd/virtualization virtualization.tex

[www]

www		Tue Mar  4 16:18:00 2008 EDT

  Added files:                 
    /modules/gerd/virtualization	virtualization.tex 
  Log:
  Virtualization project
  
  

Index: modules/gerd/virtualization/virtualization.tex
+++ modules/gerd/virtualization/virtualization.tex
\documentstyle{article}
\begin{document}
{\Large\sc Username ``Virtualization'' in LON-CAPA}
\section{Problem}
\subsection{Issues to be addressed}
\begin{itemize}
\item Student changes username (potentially mid-semester), needs access to old data
\item A student gets a previously assigned username
\item Both of the above happen in either order
\end{itemize}
\subsection{Constraints}
As a networked system of servers at potentially different software versions, we cannot rely on the session server being up-to-date. As much as at all possible, all virtualization should happen on the homeserver. {\it A versioned user might work on or be offloaded to a server that runs an older version of LON-CAPA}. If a conflict with an old session server is unavoidable, things have to fail in a predictable and controlled fashion. The homeserver of a course may be different from the homeservers of its students. The homeserver of the course may be on an old version.
\section{Proposed New Structures}
\subsection{New User Types}
Currently, we have two ``user'' types: users and courses (courses are actually handled like users). Proposal for two new types:
\begin{itemize}
\item Retired user: the user is not active anymore
\item Symbolic user: this is just a username, the real data sits under another username
\end{itemize}
The homeserver for these users has to on the newest version of LON-CAPA.

A domain could have several library servers. All versions of the same username need to be on the same library server. All symbolic usernames referring to another username need to be on the same library server. Symbolic usernames cannot be chained, they need to point to the original ``real'' user.
\subsection{Versions}
Usernames can be versioned: {\tt susie:msu}, {\tt susie$\sim$1:msu}, {\tt susie$\sim$2:msu}. Unversioned usernames are version 0. They can also be addressed as  {\tt susie$\sim$0:msu}

The character $\sim$ is not allowed in email addresses (thus, cannot be part of a LON-CAPA username), but is explicitly allowed in URLs.

Only one version of a username can be active at any given time.

In addition, {\tt susie$\sim$active:msu} may exist as a symbolic user pointing to the active version of the username.
\section{Controlled Breakage Policy}
Unless otherwise noted, homeservers support unversioned access unless there is ambiguity.
\section{Functionality That Needs to be Supported}
\subsection{Authentication}
The user logs into any server in the network. However, authentication is provided by the homeserver. The user enters his or her unversioned username, but since only one version of a username can be active at any given time, there is no problem.
\subsection{Data storage for the user}
The user works on any server in the network. Data is sent in the unversioned form, but since only one version of a username can be active at any given time, there is no problem.
\subsection{Data storage for the course}
Here, problems arise due to double storage (at some point, the project deviated from its "single data source" strategy).
\begin{itemize}
\item Classlist - can we tag the username's version into the classlist, so that the classlist is still readable (unversioned) for old servers?
\item Discussions
\item Activity Log
\item Group Membership
\item Face-to-Face User Notes (?)
\item Student-Viewable Course Roster with Portfolio Information
\item Caches for Spreadsheets (do not expire until explicitly devalidated)
\item Caches for Charts (automatically expire)
\item Already Generated Named Exams
\item Potentially Written Down Receipts
\end{itemize}
\subsection{Mail Messages}
What is hard-coded into the messages? Apply controlled breakage policy. You cannot reply to old emails (not even on a new server) if there is ambiguity. Going forward, all emails need to have versioned usernames. 
\subsection{Authored resources}
These have to work with the fully versioned username. This is compatible with old versions of LON-CAPA as long as no username match is run on the URL parts (appears to split by slashes, not username match). Since authoring happens on the homeserver, and that must have a new version of LON-CAPA, we can catch it and make sure things get published with the versioned username (LON-CAPA construction space functionality can safely be changed).
\subsection{About Me}
Data for the About Me page comes from the homeserver of the user. If the unversioned username is given, the active user's page is brought up. Versioned username pages can be brought up (explicit version 0 for the original user). If you look at an old classlist, you get the new user's About Me page.
\subsection{Portfolio and other userfiles}
Example: {\tt /uploaded/msu/susie/...}. Currently does username match. You must not be able to access userfiles from retired users. Possible problem: susie$\sim$2 upload foo.html for a course, subsequently retires. susie$\sim$3 also uploads foo.html. If looking at the old course, you get susie$\sim$3's foo.html instead of susie$\sim$2's, and there is no indication of the problem.


\end{document}