May will be “MLX” month. Or “Mad Mad Mad” month. We will be madly tinkering to try and ready an open source version of the Maricopa Learning eXchange (MLX).

It has not been of lack of interest that has kept this from happening, but shortage of time, staff (we are a team of 1.5 developers and plenty of other projects lined up in addition), and mostly, nightmares of having to actively support software development, something I have no experience or great desire to take on.

So this will be a first, semi-informal outline of ideas for “openMLX”, a request/offer/plea for those interested to get involved (maybe a sanity check). We will be working on a first prototype from one of our test servers, and run a test MLX for another department in our area, and (paws crossed), some sort of announcement at the June 2004 New Media Consortium Summer Conference

So here goes a few items on the table…

Preliminary Steps

  • Consult with our legal department, and get their approval. If this bombs, end of project. (pending)
  • Create SourceForge site to support development (done) I just need to figure out how to set things up.
  • Scope out current MLX features, and identify specific areas that have hard coded stuff that needs to be generalized , modularize what is now a large code library. (in progress).

Pie in the Sky Grand Visions

  • This new version will be called “MLX”- I struggled for a suitable acronym to replace the “Maricopa” (“mighty”, “mega”, “momdo”, “mediated”, “modern”), but latched on to the suggestion of David Carter-Tod to do a geeky recursive acronym- “MLX” stands for “MLX Learning eXchange” – get it? Projects will be labeled as an “openMLX” project”
  • MLX will be simple. Features are desirable, but we are not going to add any extra functionality that is not there now. Please remind me of this often.
  • After some e-mail discussions and ideas, we are likely settling on the GNU General Public License (GPL), pending discussion with our legal department. Your own installation must contain what will be a fixed credits link to Maricopa and the original MLX site.
  • MLX will retain the warehouse, loading dock, package metaphors. You cannot change ’em and those are our “property” in terms of IP
  • MLX will be designed for LAMP platforms (Linux-Apache-MySQL-PHP) all OS tools. You are welcome to install it on that Windows 98 box, but may the force be with you cause I won’t.
  • MLX will be relatively easy to set up,. but not a click here button. Files will need to be ftp-ed to a server, mySQL will need to be set up and a database/user access created. There will be one or more text configuration files to edit. It should be something on the order of what is needed to set up MovableType, if you have ever done that. Some technical required to set up, but certainly not much.
  • Some amount of local customization (appearance) will be available. Do not bug me if you do not know what a CSS class is, stay with the out of the box style.
    • Local header/footers can be added to all MLX pages, with layout defined by simple include files and CSS. They can be hidden as well with CSS.
    • The config files will allow you to create whatever local name you have for your MLX, used site wide, e.g. “Bo Diddly School of Strumming MLX”
    • Sigh. The layout now is a mix of HTML tables for layout control (ducking tomatoes, but hey, this was designed first in 2000, and still looks okay on those crufty old browsers). A future pure XHTML/CSS may be down the road, but it is low priority. Most of the styling will be taken out of the HTML table code and be accessible to modify things like main button color via CSS.
    • We will add print style sheets to better structure printed page styles.
  • You get the following features currently available in the MLX:
    • Categorizing / Searching within custom defined fields. Currently the MLX is organized around search filters based on the organization of the Maricopa system, our ten colleges. This will be a locally defined list now, so one could create filters by department, topical theme, favorite color, etc.
    • Search by keyword on all fields, category field (see above) subject discipline, package title, package description, author’s name.
    • Ability to create MLX Special collections. We need to build a simple admin interface for allowing control over this.
    • RSS Syndication– you get it all too. Newest items site-wide, newest by category, by special collection, by individual contributor, and any search result. A fair bit of leg work needs to be done here as the current set up is handled by a unix cron script that updates some feeds every hours, others are dynamic. The plan is to create some cache holding system, so that admins can define how long a feed showed be cached, and once the time has passed, MLX will create a new one on the fly. It will come with its own, linked in version of our RSS to JavaScript tool for allowing easier cut and paste RSS subscribing. Current Syndication uses a RSS 1.0 library that works like a charm .Someone will need to twist my arm or write something plug and play to change that.
  • A refined MLX Packing slip. We have already prototyped changes in the comments mechanism with the form now embedded on the slip, with 1-2 most recent comments, and a link to see the rest. Package authors will have the ability to hide nasty comments. (in progress) A possible new feature is the ability to link/credit to other “related” MLX packages, e.g. is Jane finds Bert’s MLX package on a critical thinking activity, she may modify it enough to create a new MLX item- it would be cool (to me) to allow Jane to easily credit Bert’s original package. Kind of like a Trackback but not exactly.
  • Recoding the TrackBack mechanism. The MovableType TrackBack data storage is hard to manage (binary files), and does not make for an easy way to easily count numbers of TBs. I am hoping to modify the mt-tb script to write to the MLX database directly. MLX packing slips already are embedded with the code for autodiscovery by trackback.
  • Use accounts is probably the most challenging area. We are planning to design the code so you can write your own functions for authenticating accounts against some external system, and just pass back to MLX the needed details to let people in. We will likely provide two different approaches that could be done w/o any further coding:
    1. Completely open- anyone can create accounts that allow them to put stuff in an MLX. To limit access, one could put the entire site inside a password protected directory, and thus have a “private MLX” (this has been one request).
    2. A simple admin approval. Account requests will be queued, the admin notified by email, and they will use a simple admin interface to approve/deny account creation, and an email will be sent to the requester.
  • We have left in the current MLX slip, a link option to generat Dublic Core meta data for a package. Someone somewhere may actually have a use for that.

Help Wanted

  • I am looking for the early adopters that can handle an alpha version without hand holding. If so contact me, and create a soureForge account for your self so I can add you to the developer list. SF has listservs, documentation cubbies, and even RSS feeds for project updates– (nothing is there now).
  • I am looking for general ideas that can help define the ways MLX can be used with other organizations, to make sure we are not missing a key feature (but see note above- this will not be bloar-ware).
  • I could use someone with better mySQL database knowledge to review our db structure and queries, but someone who can understand the external functionality of how it works. I am a pretender with db design. I read a book.

Well, that is a brain dump for now. Maybe no one is interested, and I can go work on something else. And I vow this will stay simple. Otherwise, toss a rawhide bone at my skull.

The post "openMLX" was originally scraped from the bottom of the pickel barrel at CogDogBlog (http://cogdogblog.com/2004/05/openmlx/) on May 5, 2004.

2 Comments