Code Immersion

Also posted to my personal blog at http://ianmcorvidae.net/

This post will go through each of the files of the code-immersion package and describe their function within the package. Files are in no particular order, but hopefully hopefully minimal things will rely on stuff described in files later in the list.

• COPYING and README: These should be the most transparent: COPYING is the license for code-immersion (it’s licensed under AGPLv3; for more information see the Free Software Foundation site http://www.fsf.org/licensing/licenses/agpl-3.0.html). README is the horrible underfunded help file I created, which needs improvement (that is, I need to write a real manual… someday).
• config-example.ss and config.ss: The first of these files is an example configuration file. The latter is the actual configuration file. This determines some universal things like one’s name, the location of the server and daemon, ports, and more low-level things. Almost everything else relies on the configuration, understandably.
• utilities.ss: This has some basic definitions which aren’t really configuration parameters, but which shouldn’t be defined in multiple places either. Stuff in here is used by all of server.ss, daemon.ss, and client.ss.
• datastore.ss: This defines the data-storage system(s). Currently, only the daemon actually uses this, but it’s something which could easily be useful for other programs, so I decided to separate it out. At the writing of this, the only type of datastore is a hashtable datastore (and an aborted attempt at a list datastore), but this could be extended (and probably should be).
• server.ss: Here’s the first file that has the real guts of the software. This is where everything that actually makes the server work resides. In fact, this is only four functions specific to this file (it uses utilities.ss and config.ss as well): register-client (which makes sure that a client (daemon, really) gets added to the list of places to send code and text), get-output-port-list (an internal function used by…), dispatch (which actually sends code and text out to daemons), and server (which is the server, which rolls all of this together and makes it useful).
• daemon.ss: Here lies the first half of what you-the-user know as the client. The daemon is the section of the client which registers with the server, receives code from it, and which stores things for the other half of the client to use, providing ways to access this data.
• client.ss: The other half of the client. This provides all the functions by which one sends text and code to the server and by which one retrieves text and code from the daemon (and additional functions to evaluate code after it’s retrieved).
• runclient.ss and runserver.ss: The first two of the convenience programs for actually using the software. runserver.ss runs the server without requiring any futzing-about with configuration files or explicitly starting anything. runclient.ss runs the daemon in a similar way, but asks for information for the configuration file which individual users might want to provide.
• project.ss: The final convenience file, this doesn’t really do anything; it’s just a stub of a file which uses a (require …) form to allow someone opening and running it to use all the functions provided by client.ss. This is where end-users who don’t know much of anything actually write code and use the software.

Questions/comments/concerns should go in the comments section below!

This entry was posted on October 6, 2009 at 10:48 am and is filed under Uncategorized.

Tags: code-immersion software package