Will Guaraldi
Thesis -- distributed systems in On-Line education
April 17th, 1998

introduction

The computer industry is changing very radically. Hardly a week goes by without some serious new technological development or idea announcement. We are in the middle of an information revolution--caused by the advent of cheaper and faster computers, and high bandwidth connections between them. The Internet--the largest world network connecting vast numbers of people and institutions provides a virtual production area for mass communication, archiving, research, work, play, information processing, data transfer, social interaction, so on and so forth which is platform and location independent.

Every aspect of our society has begun to spawn off an Internet-based on-line version. The Internet provides interconnectedness between systems, groups, and individuals on different platforms at different locations. It also provides for the rapid transport of data between systems. We have on-line investing, banking, job-hunting, social gatherings, gaming, businesses, libraries, shopping, and entertainment to name a few. Naturally, education is also progressing towards the Internet. Already various colleges have schools that are entirely based on-line--the next step beyond commuter students: distance students. Some of these students are working mothers taking classes at night. Some are located in Italy taking classes in Arizona. My friend is taking classes at Harvard from our computer lab at Boston College.

However, education differs from all the things above in that it cannot be compromised--elements of education cannot be removed without penalty to learning and to becoming educated. Imagine a college teaching classes to future carpenters--and the class being on-line never exposes these students to a board or a nail. These are physical things that cannot exist on-line... or can they?

overview

I am working on a distributed system that allows for future expansion as the technology grows. The core of this system must be simple to extend, efficient on resources, easy to administrate, easy to use, contain the necessary facilities to support new technology, and provide for a robust educational environment.

I am focusing on buiding, from the ground up, a groupware system for platform-independent distributed applications geared towards an on-line educational environment. This system will enable a group of people to simulate the classroom environment--any classroom environment whether it be MC362 Computer Networks and Distributed Systems or MU083 Improvisation in Blues and Jazz.

This thesis document is a written account of the project and the various attempts at solving the problem at hand. Each attempt is a full account of the system specification, the various objectives the new system solved, the various reasons the system was abandoned, and my thoughts.

This project is designed to explore the system architectures for systems that would support on-line education--both as it exists now, and as it may exist in the future.

chapter 1: Other People's On-line Education

1.1: The Days of MOLI on MSN
Back during the summer of 1995, Microsoft rolled out their first on-line classroom setting. Originally, it was on their on-line system MSN and it was wholly chat-based. The instructor would assign readings for the following class, the students would read the material, and the instructor would question them vigorously on what they read while adding various tidbits of information that the text didn't cover. I was one of the beta-testers and I was taking a course on Microsoft NT Server fundamentals.

I remember feeling isolated. Sure I read most of the material before class started, but the actual class time seemed silly. It watered down to advanced self-study. The fine line that exists in classrooms between instructors teaching and students self-teaching wasn't there. I was learning all the material on my own and class was dedicated to fifty questions. This was hardly a decent solution for on-line education. For one thing, it required all the students to be using Windows 95 and have an account on MSN.

1.2: The Move to MOLI-WWW
In the summer of 1996, I taught my first class on MOLI. This was a different MOLI than the one previous. This version of MOLI was web-based and worked in your browser. However, this was long before the advent of on-line applications, so it was extremely primitive and took forever. I would post a response to one of the students questions and wait 30 seconds for the system to refresh so my students could see my response. Then another minute later and responses to the responses would appear (assuming that the students could touch-type).... Too much time was wasted. However, this new version of MOLI had all the courseware on-line in web-pages in another area of the classroom environment.

I was teaching a course on web-authoring. Since this system was in web-pages, I was able to teach by example and show my students what the various HTML tags did. Class was no longer just desperately attempting to explain concepts using language which lacks the preciseness required.

1.3: Asynchronous Learning Networks
The Sloan Foundation (http://www.sloan.org) offers grants for those pursuing Asynchronous Learning Networks. The focus of ALNs is to provide an education outside of a classroom unit. Students learn at their own pace. Those that are "highly motivated" will excel quickly. Those that aren't will take their time. Some of the institutions to get grants have created an on-line environment based on web-pages that contains courseware and communication via email. But this isn't so different than degree-by-mail systems.
1.4: Distance Learning
At the end of the Summer of 1997, Microsoft officially ended MOLI. They said there was no point in centralizing all on-line training for Microsoft products on their servers--rather each Authorized Technical Education Center could host their own MOLI server with their own resources using Microsoft products. (http://www.microsoft.com/education/hed/online). They use the words "distance learning" to describe their vision of on-line education.

In distance learning, the classroom is physically replaced with web-pages of courseware, and streaming media of instruction. In this way, you see your instructor pointing and gesturing in front of you as if you were in the classroom. If you desired, you could replay bits of class because it's all online and saved on a streaming media server. But how different is this from degree-by-mail with video tapes?

On-line learning over the Internet shouldn't be limited to just replicating the classroom with a virtual classroom. Classes should be able to utilize the digital pathways of the Internet in a dynamic way via distributed applications and computing. Thus turning the classroom from a community performance into an integrated mish-mosh of thought and detail.

chapter 2: Objectives

2.1: Overview
This project is based on classic client-server design model. In this respect there are two main pieces to the system: the clients and the server. The server to client relationship is a one to many relationship as one server serves multiple clients. Each client is run by a user and is a singular member in the classroom.
2.2: Simple to use API for Application Programming
One of the things that allows a system to be successful is the programming API. The reasoning behind this is that a simple API makes it easier for application programmers to interface with the system--making their jobs of building applications much easier and less painful.

Operating systems all have APIs to allow application programmers to build programs that work with the operating system in a nice and organized fashion. Database systems have APIs that allow application programmers to extend the functionality of the database or to build applications that use the database as a back-end. My system will have an API that allows application programmers to add education-related applications to the system. The API will be on the client-side probably in the form of a class that they can extend to gain the functionality they need.

2.3: Efficient Use of Resources
It's important for both the client and server to be efficient with resources such as file storage, memory allocation, and code speed. While the computers do get faster every three months, on-line education will be targeting a group of people who will not have the latest and greatest hardware and software.

The class that I taught on MOLI-WWW consisted of two students who were full-time mothers taking night classes in hopes of getting a job doing web-programming. While this system should be able to cater to higher-end applications for classes for Electrical Engineering and such, it should also be able to cater to classes for the layman.

In that regard, it is very important for the client to use resources as efficiently as possible.

It is also important for the server to be efficient in speed because it must be able to handle more than one classroom.

2.4: Easy to Use GUI
The Graphical User Interface is the first thing people see when they use an application. It is also the sole layer that they interact with to manipulate the application. There is no reason for a complex GUI and therefore it should be both simple and easy to use.
2.5: Extendable for the Supporting and Embracing of New Technology
The computer industry changes every day. Many of the changes are improvements over existing standards or methodologies. For a system to work well and last for a couple of years, it is vastly important to embrace the existing standards so that as they evolve, the system may also evolve.

It is also important for a system to have mechanisms that enable it to embrace new technologies via the addition of modules or additional layers. This isn't the highest priority of this thesis project, however it will be something I consider as I go along.

2.6: Provide for a Robust Educational Environment
The ultimate objective is to provide for a robust educational environment--one that can support all sorts of classes and a meaningful way that takes advantages of the electronic medium.

chapter 3: Implementation 1

3.1: Overview
The first implementation attempt was to modify and extend the existing system of the project I worked on last year. We called the project DCOMP which stood for Distributed Computing. The system involved classic client-server design. This design had some significant advantages because it didn't limit users to a specific OS or hardware platform. The system worked within a browser interface. Since the requirements of the system on the browser allowed for a wide variety of common browsers, the user had all the software he/she needed without having to download and install new software. In this way, using the system was simple.
3.2: The System Specification
The system is based on classic client-server design. Thus there are two sides to the system: the server-side and the client-side. The two sides communicated via TCP/IP protocol--the standard network transport protocol of the Internet.

See Figure 1 of the included system design spec sheets.

3.2.1: The Client
The client side worked within a web-browser interface. The web-browser had to be able to run Java Applets written with the Sun JDK 1.0--but this was the only real requirement. In this way, the user could join a class without having to manually download and install any software--the system downloaded the applets it needed on its own.

The user would launch their web-browser, open the system web-site, click on the Interface link, log into the system, choose a classroom/group to join or create a new classroom/group, and then the Interface CGI would serve an HTML page with the applets embedded in it that were specific to that classroom/group. The user was a part of the classroom/group and able to use the applications that classroom/group was using.

The client consisted solely of a web-browser that support Java Applets written using the Sun JDK 1.0. This made the installation of the client as easy as could be.

3.2.2: The Server
The server side consisted of two components: the ADMIN server and server modules. The ADMIN server was a one-thread process built in C on the Unix platform (DEC Unix 4.0). It used TCP/IP to communicate with the client-side applets and the server-side modules as well as other ADMIN servers. Server-side modules could be built in any language (C, C++, Java, Tcl, PERL, ...) so long as it communicated via standard TCP/IP and the system protocol with the ADMIN server. Choice of which programming language to use for the Server-side modules was up to the programmer.

The server side also required a web-server (built by someone else) which was capable of serving up the static system web-pages and which also was capable of running CGI programs written in ANSI C with Berkeley-style sockets.

Also on the server side was the Interface CGI. The Interface CGI dynamically built the HTML pages the user would see in their web-browser based on information in the ADMIN server.

3.2.3: The Application
An application on this system would consist of two pieces: the client-side applet and the server-side module. These two pieces together formed the application.

As an example, consider a chat application that allows users to talk amongst themselves. User A types some stuff in a text box, clicks on the Send Message button and then that message travels to all the other users in the classroom/group.

In this case, the client-side applet would consist of the user interface (the textbox, the button, and the second textbox which displays what others have said) and the server-side module would consist of the logic behind what the server should do when it gets the message.

Specifically:

  1. The message is written by User A in the textbox in the client-side applet.
  2. User A presses the Send Message button and the client-side applet sends the message to the ADMIN server.
  3. The ADMIN server gives the message to the server-side module to deal with the message.
  4. The server-side module sees the message and according to its functionality sends the message back to the ADMIN server telling the ADMIN server to send the message to everyone in the group (a Broadcast).
  5. The ADMIN server sends the message to the client-side applets of everyone in the group.
  6. The client-side applet sees the message and displays it in the textbox of what everyone has said so far.

Separating the server-side logic from the client-side applets allows applications to store files on the server such as log files or documents. Since there is one server-side module for all the client-side applets in a classroom/group, the server-side module can use information about the clients to manipulate the data from the clients. Applications can range from simple chat applications to document-editing applications to multiplayer games like Doom or Quake.

The application was composed of two things: the client-side applet and the server-side module.

3.3: System Advantages
3.3.1: OS/Hardware Independence
The system allowed clients to be using any OS/Hardware combination so long as they could run Java Applets built using the Sun JDK 1.0 compliant browsers such as Netscape Navigator and Microsoft Internet Explorer. This theoretically opened the system up to Macintosh, Unix, and Windows clients, and any clients of future OSs without changing any of the code and without having to code for any specific platform.

3.3.2: Ease of use
From a user perspective (the student), they would launch their browser, connect to the web-site, login in, join a classroom and they were off. They didn't have to install any new applications (assuming they had a web-browser that supported Java Applets written using the Sun JDK 1.0). In addition, the web-browser supplied an interface that they were already familiar with.

3.3.3: Application Independence
The system separates its inner workings from applications. It also gives programmers the hooks required to add new applications to the system without having to change the system code. If a professor were to decide they need a special Blackboard application that visually simulates drawing on a chalkboard, then they could go and build one using within the constraints of the server-side modules and the client-side components.

The system is not tied to any specific application.

3.3.4: Location Independence
The client side of the system works within the browser interface. Because the requirements for browsers is so low (namely the browser needs to be able to run Java Applets written using the Sun JDK 1.0), the browsers that work with the system are fairly common. A user could go to class in the system from home, then attend class from work. The physical real-world location of the computer that they use to log into and interact with the classroom is unimportant.

3.4: System Disadvantages
3.4.1: The System is Difficult to Program for
The programmer is granted a lot of flexibility on what programming language he/she chooses to write the server-side module in. However, the client-side applet must be written in Java using the Sun JDK 1.0. In addition, the server-side module must be launched from a command-line and cannot have any user-interface. Errors in an application will be difficult to discover and require the ADMIN server environment to test and debug making creating applications for this system a tedious and difficult process.

3.4.2: Because Java is Limited, Applets are Limited
Java is a language. Java Applet and Java Application are standards for how a Java program is structured and what it can do in terms of accessing the client's system. Java Applets are the only Java programs that can run inside a web-browser interface. When they are launched inside the web-browser they are launched with a security sandbox which prevents them from accessing the computer they are on in any way. Also, Java Applets can only make socket connections to server programs on the machine the web-browser downloaded the applet from. This gives the client some security and prevents them from downloading applets accidentally that can do harm to their system. However it also severly affects the things applications running on the system can do.

Java is also a very immature language. The GUI components of Java (the things that make up what you see and interact with as a user: menus, buttons, windows, textboxes...) are horribly designed and implemented and are extremely slow. Since Java Applets are the only "standard" that is supported across multiple browsers, there are no other options for providing application functionality inside the web-browser interface.

3.4.3: The ADMIN Server is a Bottleneck
The ADMIN server is the center of all activity in the system. All messages get passed through the ADMIN server--sometimes more than once--before they get to their destinations. The ADMIN server keeps track of a bazillion network connections--one for each server-side module and one for each client-side applet. One class with 10 students and 3 applications running involves 33 network connections. Large classes or multiple classes will cause the ADMIN server to run increasingly slower.

The ADMIN server is perfect for one or two small classes, but since no educational institution has just one or two small classes running at the same time, the system isn't very useful.

3.5: Abandoning the DCOMP Modification and Extension
The DCOMP-type system must be abandonded. The limitations on the client-side because of Java Applet restrictions and the limitations of the ADMIN server because it is the center of the entire DCOMP system are too great to be useful to an educational institution of any level of seriousness.

Also, since the makers of the various web-browsers are suing each other over Java functionality, there's no sure way of assuring that a given client-side applet will work in all the Java v.1.0 compliant web-browsers almost guaranteeing compatibility problems between browsers and platforms. Since the reason for using client-side applets was for platform independence which because of compatibility problems is exceedingly unlikely, I abandoned the Java Applet approach and instead build full-fledged Java Applications on the client-side.

Creating an on-line education system should attempt to cater to as many people as possible while still retaining a high level of funcionality. This system catered to a wide audience, but turned out to have a few posibilities and serious problems with compatibility across the leading web-browsers.

chapter 4: Implementation 2: Miloc version 1

4.1: Overview
My focus is to increase the functionality of the client thus increasing the posibilities of applications that it can support. I am taking the obvious step of moving from Java Applets to Java Applications. This creates some problems in that I can no longer use the web-browser for logging into the system, joining classrooms, and downloading the client-sides of the applications... I have to build my own.

While I'm at it, I decide to move the server-side from the C language on the Unix platform to Java on Windows NT. I do this for a number of reasons. First, Java does multi-threading much easier than C does--in a less proprietary way. Second, my Windows NT machine is a stronger and faster platform than the Unix platform the Computer Science machine is on. Since Java applications are platform independent, this would enable me to run the server side on any machine that had a Java 1.1 VM on it.

Also, I'm switching from using the Sun JDK 1.0 to the Sun JDK 1.1.5 because it is the most recent version of the language VM and the compiler and the GUI is better, easier to code with, and more powerful.

In addition, this implementation became known as Miloc version 1.

4.2: The System Specification
Since Java is an object-oriented language, the System model will look differently than it did in the first implementation.

See Figure 2 of the included system design spec sheets.

4.2.1: The Client
The client of implementation two was composed of a series of components rather than a web-browser hosting a series of applets. This replaces the applets, the web-browser, and the Interface CGI from implementation one. The user starts the client and then logs into the server and joins a classroom. The client then grabs the Miloc Apps from the server and displays them in the applications panes.

The client is composed of the MiClient, the MiClientGUI, the AppManager, and the ClassListener. Since Java is an object-oriented language, these components are all unique objects with specific functions that they perform in the system.

The client (and all components of the client) was written in Java using the Sun JDK 1.1. It doesn't have any system specific code and can theoretically work on all JDK 1.1 platforms. However, this was complete platform independence was never fully tested. It does work in Windows 95 and Windows NT 4.0.

4.2.2: The Server
The server, much like the client, is written in Java and thus broken down into a series of objects. The object hierarchy is focused on groups of users. Hence the breakdown into groups which manage clients, and a group manager. There is the MiServer, the ClassroomManager, the Classroom, and the ClassListener.

Just like the client, the server was written in Java using the Sun JDK 1.1. During development, it was tested and ran just fine on Windows 95 and Windows NT 4.0 platforms.

4.2.3: The Miloc App
The Miloc App is completely different than the applications in the first implementation. In the first implementation, an application was composed of a server-side module running on the server as well as client-side applets. The reason for this was to allow data storage for the application. Since applets cannot store data on the client machines due to security restrictions of the Java Applet specification, the server-side module was absolutely necessary. In the Miloc system, since I am using Java Applications which have no security restrictions and can open and close files on the client, there is no need for server-side modules of any sort. Thus all the logic of the application and combining with the rest of the class is in the Miloc App.

When a client joins a classroom, the Classroom sends all the Miloc Apps to the client which get launched and managed by the client's AppManager. The Miloc Apps then communicate amongst each other via broadcasts and whispers where a whisper is directed at one client in the classroom and a broadcast is directed at the whole group. Miloc Apps are extended from the MiApp class which contains all the necessary functionality to function within the Miloc client.

Since I am using the Sun JDK 1.1.5 and building Java Applications as opposed to Java Applets, the GUI is much better and the Miloc Apps are much much less restricted in potential functionality than the implementation 1 applications. Also, since there is no server-side module involved adding another layer in the communication process, communication between clients is much faster and more efficient. This method also makes the server much simpler to build and keeps the secretarial job of the server much simpler.

4.3: System Advantages
4.3.1: Better Client Programming
The client is now wholly built in Java using the Sun JDK 1.1.5. Since it is also a Java Application and no longer a Java Applet, the functionality gains increase tenfold. Programmers can now have Miloc Apps access the local client file-system, create other network connections to other machines, and use the full range of Java GUI functions.

Also programmers only have to build one thing in one langauge in order to build a Miloc App. All the application logic is now in the Miloc App on the client rather than separated into two places. Because the MiClient keeps track of the other clients in the classroom, Miloc Apps have access to full knowledge of how the classroom is set up, who is involved, and what other Miloc Apps are out there.

Also, since MiClient abstracts the networking and much of the Miloc App management from the individual Miloc Apps, Miloc App programmers only have to extend the MiApp class to access this functionality leaving them to just implement the actual application.

4.3.2: Platform Independence for Server and Client
Both the server and the client are written in Java using the Sun SDK 1.1.5. Any platform that supports the Sun JDK 1.1.5 can run the server and the client. This allows for a wider variety of systems, though it's not absolutely necessary on the server side.

4.3.3: Better Client GUI
MiClient allows the entire client interface to be the same including Miloc Apps. In implementation 1, the interface was primarily a web-browser which then spun off a zillion frames each one with a different application creating window chaos. MiClient holds all the Miloc Apps within the Upper and Lower application spaces making the interface for all the Miloc Apps simpler and more organized from the MiClient central console.

4.3.4: Ready for Tomorrow's Technologies
The client and the server are composed of a series of objects which centralize many of the aspects of the two programs. As new technology comes, the individual objects can be replaced with better functioning ones without having to rebuild the whole system or even either the client or the server. This is one of the main advantages to object-oriented programming using object-oriented languages.

4.4: System Disadvantages
4.4.1: Server is Very Slow
Java is an interpreted language rather than a compiled one. This allows a programmer to "compile" the Java code into Java Bytecode which is platform independent. C, C++, Cobol are not like this. They are compiled into machine language which is then specific to the machine it was compiled upon. I cannot run programs compiled on a Unix system on my Windows NT Workstation, for instance.

Being an interpreted language, Java programs suffer from having to go through a program which interprets the Java Bytecode and then performs the instructions. This takes a lot of time.

In addition, Java doesn't allow programmers to manage memory--the JVM does all the garbage collection on its own. When the JVM decides to clean up memory, the server will stop for a few milliseconds while the garbage collections runs, then it will resume. In a mission critical application like a server, this is a very poor characteristic to have.

Lastly, Java's object model forces programmers to build three or four separate layers in order to access input and output streams. Each layer takes time to pass through. The Miloc server depends very heavily upon fast network packet turnaround--and because both the input and the output stream are 3 to 4 layers thick, this is nearly impossible.

4.4.2: Server Object Model is Group Oriented
I had finished the basic functionality of the server and the client and I had built a simple Miloc App called PaChat. PaChat was very simple--it allowed clients to chat over the network in groups.

Then I realized that the object model of the server was such that it was group-centric. Classes are not necessarily a group. They have a series of students, but one member of the class, the professor, has a different set of abilities and permissions. The instructor had to be treated differently than the students and the Miloc server didn't allow for this without a medium amount of redesign and modification.

4.4.3: Miloc Protocol is Still Very Proprietary
Though this isn't a severe disadvantage to the system, it would be nice if the Miloc Protocol was based on another protocol. This makes the system less proprietary and adds the possibility of integrating with other Internet applications.

4.5: Abandoning Miloc version 1
The biggest problem with Miloc version 1 is the incredible slowness of the server even with a really light load. When I was testing the server and the client with my PaChat application, there was about a second lag between sending a message and receiving it on the other clients. A whole second on a server with only one classroom and three class members on it. While the server could support limitless numbers of classrooms and members from a theoretical standpoint, this lag prevents it from being a practical solution at all.

Given that severe problem, I was forced back to the drawing board. Java was no longer a solution for the server side, even though it allowed the server to be portable amongst various platforms. I decided to go back to writing C code. This time, I downloaded the CYGWIN implementation of the GCC utilities for the Win32 platform. The next implementation would be based on the Win32 platform because its infinitely more common than DEC Unix--especially since Compaq bought Digital early in 1998 and it looks like DEC Unix may be on its way out. The market place guides our lives even still.

Now that I'm definitely going to rebuild the server, I decide to make some heavy modifications to the system design. When I attend a class, I end up buying some sort of textbook. When I was teaching classes on MOLI-WWW, the text was on-line along with the classroom. The tying of the materials and the classroom environment allowed for some very interesting classes because I could point the students directly electronically. I decide to change the Miloc protocol to something that is just like HTTP--which is the protocol used on the Internet for the transporting of web-pages from web-servers to web-browsers. In addition, the Miloc server would integrate the serving of this material with the class itself. I would add HTTP-server functionality to the Miloc server.

chapter 5: Implementation 3: Miloc version 2

5.1: Overview
Implementation 3 became entitled Miloc version 2 as it retains the entire client from Implementation 2. I ditched Java on the server side and went back to code I had from Implementation 1 and completely rebuilt it. In the process, I added functionality for HTTP web-server.

This implementation also involved some quick changes as I was designing and coding it. The biggest of which was moving from the CYGWIN Win32 GCC compilers to Visual C++. Even though I'm writing in C, Microsoft Visual C++ opens up the Win32 API more than the CYGWIN Win32 GCC compiler did. This allows me to do multi-threading, file locking, use the Win32 registry for initialization information, so on so forth. It also has the side-effect of binding me to the Windows NT 4.0 operating system for the server side, but I believe this to be a decent trade-off for the speed increase that I should get.

Adding web-server functionality also allows classes to use data that Miloc may not recognize using their web-browsers. Art classes could have VRML worlds of the Sisteen Chappel and the students could virtually walk around.

5.2: The System Specification
See Figure 3 of the included system design spec sheets. 5.2.1: The Client
The client looks just like the client in Miloc version 1 except that I have rebuilt the ClassListener object--the object that had all the networking code in it. This was the only object that was involved in speaking the old Miloc protocol. Once I changed this object, the rest of the client worked fine.

The client (and all components of the client) was written in Java using the Sun JDK 1.1. It doesn't have any system specific code and can theoretically work on all JDK 1.1 platforms. However, this was complete platform independence was never fully tested. It does work in Windows 95 and Windows NT 4.0.

5.2.2: The Server
The server is a different story and is the focus for this implementation. I have again switched languages--going back to C. C is not an object-oriented language, so the server is composed of one component again. This has good points in that it will run much faster because I can manually tweak the code without having to worry about going through layers of objects. The bad points being that should something else change in the system, such as another change in the Miloc protocol, then I will have to recode parts of the server and recompile it. However, since the server no longer has server-side modules, it doesn't do a whole lot, so the number of changes that would cause a recompile are pretty small. This is an acceptable trade-off.

I have also switched platforms, from the DEC Unix platform to the more popular and more supported platform Windows NT 4.0. The server should be able to run in both Windows NT 4.0 Server and Windows NT 4.0 Workstation as the code doesn't involve any Server-specific or Workstation-specific things.

The server supports both Miloc communications (between clients) and the serving of web-pages to web-browsers. This caused a little pain because web-browsers connect to the server, issue an HTTP command like GET, wait for the information to come down the wire, then disconnect. Miloc clients must be persistant and maintain the connection. The server has to differentiate between Miloc clients and web-browsers. I do this by extending the HTTP protocol which only has 8 commands by 3 more commands: JOIN, BRDCAST, and WHSPER. The Miloc protocol now extends HTTP--a standard application-level protocol on the Internet. Theoretically, someone could build in a couple of hooks to any other web-server and host classes--they wouldn't have to use my Miloc Server.

In addition, the server is now an NT service. This means that the server runs with its own priviledges on the NT system and in the background as soon as you turn on the machine. It logs errors to the NT System Event Log just like any other NT Server application. Miloc Server is no different in its relationship with NT than any of the Microsoft BackOffice applications. Tying the Miloc Server this close to the NT OS will reduce the number of funky bugs that could occur for unexplainable reasons. It also continues the standards of NT administration. Any NT administrator that knows how to work with any of the Microsoft BackOffice applications will know how to administrate this application--the methods are all the same allowing for a consistent interface with no extensive learning curve.

5.2.3: The Application
The Miloc App is the same as it always was. However, it benefits from being able to perform HTTP commands as well as the Miloc Broadcast and Whisper commands. The HTTP commands are information-centric and focus on transporting data from one place to another while the Miloc commands were communication-centric. The merging of the two will promote the interlinking of text to communication electronically.

5.3: System Advantages
5.3.1: Follows as many standards as possible
Earlier implementations were built from scratch without basing the workings on industry standards. Originally, this was acceptable because the system didn't need to interface with any of the industry standards. Also, the server was originally built in C on Unix using standard Unix libraries. So even though it didn't conform to standards, it would have ok.

When I moved the server from Unix to NT, it because in my best interests to tie the server into the NT OS as much as possible. I did this by building the server into an NT Service and using the Win32 API as much as possible for system related calls.

When I decided to add HTTP functionality to the server, it became necessary to conform Miloc to HTTP. Having the protocol conform to a standard makes adding Miloc functionality to other web-servers much easier.

5.3.2: Intertwined class with text
This is more of a philosophical advantage rather than a technical one. A classroom is more than just a group of people and a series of applications, it also contains a set of texts. These texts can be written texts, or visual texts, or audio texts. Intertwining the texts with the applications and the people is the next stage of on-line education. In my English classes I remember many times quoting various authors during class discussion. Imagine being able to quote and give an HTTP address of the the location of that quote such that other classmates can immediately reference the quote. Imagine being able to do that for a movie or a song. "Remember that scene where young Hal is sitting on his horse and he has that sad and yet wizened look in his eyes. And he speaks to his men 'We few, we happy few...'" and then the URL for that specific moment in the movie when this happens. Imagine the chat application that you're using automatically recognizing the reference as a reference and showing that section of the movie without having to be asked.

Imagine this all voice activated.

Classes consisting of a mere chat-session, as if we were all communicating via telegrams, extended with this intertwining of text and application makes for a very powerful interactive education combination.

5.4: System Disadvantages
5.4.1: The Server is locked to the NT platform
At this point, the server will only run on NT. However, because the Miloc protocol is an extension of HTTP, it is possible for a group to extend another web-server to include Miloc functionality. This possibility somewhat alleviates the problem. Though it could be argued that this isn't much of a problem since there is one server to many many clients. The problem of having the client locked down to one platform--especially since many people still use Macintosh and many more use Linux--limits the system's reach.

chapter 6:

6.1: Conclusion
Education is vastly important in the growth of society. It allows generations of people to hand down information and ideas down to a new group of minds young and old. Education in its most popular form is location-centric. We all attend Boston College at Chestnut Hill. This requirement to be here in order to attain education in its most free form is limiting. What happens to the student that has a day job? What happens to the student who lives in Alaska with his ailing mother? What if the class is so specialized that only 30 people in the world would want to take it? Do we require them to come all the way from their wayward homes to Boston College for one class?

On-line education provides a solution to these problems and frees education that much more. However, it's going through an evolution much like classroom based education did many many years ago. As on-line education realizes its potential, we may find ourselves with a new class of students: on-line commuters. People from across the world studying a specific thing with a group of people in different time zones. Its unlikely that this will replace classroom education in the next 100 years much like its unlikely that computers will promote the replacement of books with electronic documents.

During the course of my thesis, I worked on building a system with technological constraints as well as philosophical ones. After pushing through several implementations and system-designs I am realizing that much of the technology that will be needed to build the on-line education environment I envision is still not here. While it is possible to jury-rig a system, I don't think it is possible to build the whole thing without first waiting. I believe it's important to base it on current standards because as the standards grow and change, so too will the system. The maturation of languages like Java will help, especially as it allows you to run the same program on a diverse set of platforms.

This system is better than the both the MOLI implementations because it intertwines the text with the applications--something neither of the MOLI implementations did to Miloc's extent. This system is more robust than many of the Sloan Foundation grant receivers--but only because they are focusing on Asynchronous Learning Networks and Miloc is more of a distance learning environment.

As with all systems, Miloc needs a series of applications built that work with the system. In this sense, Miloc isn't done yet. But the groundwork is there for someone else to build on top of and this was the goal of my thesis.

http://www.cs.bc.edu/~guaraldi/thesis/thesis.html