In order to understand the underlying nature of this project, one must have a modest grasp of the conceptual side of the software behind web server technology. There are two elements which make up a web server, a computer with an Internet connection and software that directs that computers communication with other computers over the internet. From here on out, when a web server is referred to, the reference will be relevant solely to the software process running on the given machine. However setting up a web server can be a daunting and sometimes a quite large project depending on the needs and requirements of the desired operational setup. Yet web-servers run on a simple paradigm such that a web browser contacts a machine on a predetermined port (the industry standard is port 80) and the web server
Prolog:
As we learned both through lecture and hands on experience, prolog is an exceptional language for writing logic driven applications in a terse and clear manner. Due to these desirable characteristics, one can find prolog in many different dialects and tongues. Currently one of the most used and availed Prolog compiler is SWI written by members of the facultyat the University Of New Zealand.
SWI offers many enhancements to Prolog in the form of modules. These modules provide Prolog with a far greater control and knowledge of the system on which it is installed. This is why I chose to use SWI as the foundation from my project.
The core of my project comes from the use of two SWI modules: html_write and httpd. Html_write is a library, which takes prolog code in the form of elements in a Definite Grammar Clause (DCG) and parses the lists inside the DCG. I will define the operation and syntax of html_write further down the page.
With all of the enhancements to SWI, I decided my best choice would be to use XPCE, which is a prolog interpreter included with the SWI installation. While XPCE includes predicates for graphical systems and menus, the prime reason to use it was for its ability to control sockets. Without the use of sockets and ports, one would not be able to see or communicate with my project. Note while there is no massive amount of input, the word communicate refers to the clicking of links which is what keeps the program in a continuous DCG loop. In order to reach a terminal, the user must stop clicking. This is an abstract view of logics processing based on the habits of the user.
Operation:
In order to break down this project into smaller pieces, I have sectioned off the code into smaller pieces and clustered the discussion based on the particular bit of codes purpose.
Server Instantiation.
The most important thing to realize in this project is that the attached code takes only one small piece of input and that is the port on which the server should stream its web pages, (NOTE: port 80 may be invalid on certain machines as those machines are configured to not let prolog broacast on such a common port due to potential security issues). The web pages are not input, instead they are written into the code although it would not be hard to create them as a separate input file.
Upon instantiation, the server is charged with executing requests with the default forward slash defined below.
For example: To activate the server you would type in activate(port). Where port is any arbitrary number. Activate 8080 would set the server on port 8080 so that it would be accessible on a web browser at http://localhost:8080.
Server requests:
When a page request is made to the server, it is the servers job to follow the DCG to find exactly which page is requested and through unification, unify the page to the port designated with input.
When the server is first view, ie: through http://localhost:8080/ there is no particular page designed so the server must have a root page propagated with links already set up, or else there would be nothing for the viewer to see unless he knew the exact links i.e. http://localhost:8080/Project.
From the / request, one can follow the page request DCG in a logical manner. It is important to notice that immediately the code unifys the webserver to the frameset and this unification will be permanent unless someone requests the root of the site again . From thn on, the human interaction with the frames controls the terminal of the grammar.
Note The unification example above has been highlighted in red. Also the root of the site is the beginning or enterance to the site. In this example and in many modern web servers, the root is the server name with out any additional page names appended to it. For example the root of brandeis's web server is http://www.brandeis.edu/ and subpages would be appended to the last '/'.
Language:
As mentioned before one of the core elements in this project is the inclusion of the html_write library. This library part of SWI’s movement on prolog in the semantic web, allows prolog code to be translated into html. In html, information/data is “tagged” where the tagging dictates the use of the data for example there are link tags or <a> tags as they are viewed in html. There are also <alt> tags which dictate alternative content for a browser which may not be able to handle the prime content on the requested site.
Html_write processes the tags similarly to the paragraph tag or <p> tag as outlined below.
For example the prolog statement p([‘This is a paragraph’]).
Translate to html code <p>This is a paragraph</p>
Or viewed on a webpage as This is a Paragraph
A tags are done as follows:
An example Prolog statement a(href('http://www.w3.org/2004/ontaria/'),target(body)]).
Translate to html code <a> http://ww.w3.org/2004/ontaria </a>
Or Viewed on a webpage as http://ww.w3.org/2004/ontaria Note the target(body) command states to send this link to the frame named in the DCG as body. See addendum on frameset.
One of the most important things that I added was an additional predicate to create a web page that takes an additional argument that sets the page background color. Therefore there is a predicate for page/2 or page/3 where page/3 is my modified version.
Why:
Now that the project has been explained, the question arises as to why someone would ever pursue it. The answer to this while quirky, rests solely on my views on educating the world on internet technologies. From a technical standpoint, the processes and systems that I outlined above sound daunting and ghastly to implement for many people and in many cases they are. However they don’t have to be and for technology to advance, people must learn about it.
Therefore there are two real uses for my project and they both fall under education.
Prolog as a descriptive logic language and education tool
The first reason has to with the syntax and inherent design of prolog. Its native logical bounding promotes the creation of easy to read structures and programs. The source code for this project follows a simple and relatively easy path in comparison to other servers such as apache, which come with multiple files, and lack an organization based on logics.
Prolog for education in Prolog
This tool is well suited as an in class presentation tool. Right out of the box, it demonstrates Prologs natural ability to adapt to changing technology. It also allows an instructor to present relevant information concerning Prolog without the use of a third toolset such as Microsoft Office. While this could be considered a novelty of sorts…
Pure Curiosity
I have always been someone who buys or receives something new and then immediately has the urge to take it apart and figure out what makes it tick. When I found discussion and samples of this project online, I knew immediately that I wanted to pursue it . With my work in web consulting, I am constantly faced with the issue of taking object X and making it look/operate like object Y. From a theorist’s stand point, this notion falls right under the auspices of programming paradigms. This project serves as yet another example of how a program as large as Apache can be imitated with simple Prolog code.
This project also helped me apply what I learned in class. If one were to view the html_write library, one would notice the consistent use of append. In order to build the pages, tags and other html elements must be appended to each other in order to construct a valid page. Without append, the pages would not be functional. Also as mentioned before, unification is crucial. In the example code below, which is a segment of the DCG that translates page requests and unifies the page to the port so that the user can view the requested page. Without this unification, the page would be unable to be viewed. This unification is an example of stream processing, something which we did not spend to much on in class.
Quick Overview of Frames:
In a simple set, frames are like a workspace with an arbitrary number of spots. You may have one spot to work on the computer, another to take notes and a third place to keep your books. A frameset works just like that. Each frame gets a name and holds a different webpage. This allows us to organize pages in a more aesthetic and operational manner. Each link on any frame can be directed to another frame. In this particular project I chose 2 frames, one I left as an index and the other was for the links clicked on in the index, this is what was referred to as the body frame.
Code for Frameset as viewed in my project
frames -->
html(html([ head(title('CS140: Prolog in the modern World')),
frameset([rows('8%,92%')],
[ frame([ src('/index'),
name(index)
]),
frame([ src('/start'),
name(body)
]),
frame([ src('/code'),
name(bottom)
])
])
])).
Code for Frameset as viewed in my project as viewed by a webserver/webbrowser. This has been parsed into html by the html_write library.
<frameset rows="8%,92%">
<frame src="/index" name="index">
<frame src="/start" name="body">
<frame src="/code" name="bottom">
</frameset>