Technical Vistas: Flat Files and APIs

It’s been an exciting time at DTLT for a bunch of reasons, not least of which is that the Domain of One’s Own project, much like the Death Star, has been fully operational for more than a semester now. We’ve learned a lot about what works and what doesn’t, and we have much more to learn this semester. We’ll be sharing out what we learned in more detail shortly, but in short: curricular integration is king.

dokuwiki-logoMoving beyond the cultural work we’re working towards with Domain on campus, there’s some technical stuff we’ve been exploring that’s pretty exciting. I’ve already wrote about the student coding projects we’re working on with professor Karen Anewalt’s Software Engineering course which should bare much fruit in the way of WordPress plugins for Domain of One’s Own and UMW Blogs. The other technical stuff we’ve been experimenting with is sharing our documentation for Domain of One’s Own. Tim Owen’s recently wrote a post about how he is using the open source application DokuWiki and Github to allow anyone interested to fork our documentation. What’s cool is that the synching between these two applications is possible because DokuWiki is using flat file storage. It very well may be that flat file CMSs will be all the rage in 2014, and far so good for us when it comes to wikis. Props to Audrey Watters for seeing the potential of Github well before the rest of us edtech hacks caught on.

The push for this setup on DokuWiki came out of our shared frustration with MediaWiki, talk about an application that wants you to hate it. And despite it’s inclination to become a spam farm within an hour of installation, I was still prepared to stay in that abusive relationship if only for the great work the UBC folks have done with WordPress plugins like Wiki Embed. But Tim and Ryan Brazell challenged my backsliding, and proved me very  wrong. I’ll happily eat crow for those two geniuses.

Kin Lane #4life

The other thing that’s got our attention as of late are APIs. Kin Lane is my hero in many regards, and his prosthletizing work for APIs has opened up a whole new world to us over the last year. I’ve known about APIs for a while, and had some vague idea of their value, but its Kin who framed for us their endless possibilities. Tim Owens has led the charge in the experimentation (he’s DTLT’s R&D), and he recently wrote a post “Harnessing the Power of APIs” that chronciles some of his early experiments. We are still in the early stages of this one, but as TIm eloquently notes:

There’s something magical about realizing that you can interact with almost any piece of software out there and build great things. There have been many instances where we’ve relied on RSS in our department to handle the bulk of the work of getting information from other systems. It’s “old reliable” in that regard, but riddled with its own issues (the future of it notwithstanding). More often than not services are not including RSS as a part of their core offering (and in some cases it probably doesn’t even make sense). But public APIs are commonplace and in most cases you can accomplish some really incredible stuff using them!

RSS is old gold, but might we need to invest more time and energy into APIs for making some of the work we are doing more seamlessly integrated? Tim was recently talking about providing a preliminary dashboard for all Domain of One’s Own users that enables them to get a domain, create a subdomain, and install an application without ever going to CPanel—all with APIs. Making things that much easier for our community to create and manage there own spaces is very powerful, and I’m stoked Tim is leading us in that direction.

DTLT, we’re not the best for nothing. NOBODY!

Also, I have to quickly note that meeting Kin Lane and Audrey Watters last April at M.I.T. to start imagining Reclaim Your Domain has proven to be truly inspiring for the work we’ve been doing this year. I can’t speak for anyone else in DTLT, all of whom are smarter than me and probably saw these developments on the rise, but I desparately needed a good schooling on flat-file CMSs, Github, APIs, and the future of the web.

OK, but enough of that, I’m off to read Roy Fielding’s dissertation.

This entry was posted in dtlt and tagged , , , , , , , . Bookmark the permalink.

11 Responses to Technical Vistas: Flat Files and APIs

  1. I’m split on the dokuwiki/mediawiki question, and I really have to decide pretty soon. So this is timely. Here’s how I see it:

    MediaWiki Pros:

    * Large developer base
    * Proven scalability
    * Standard look and syntax that inspires playing to strengths of wiki
    * Decent collection of plugins
    * Better with spam than people think when right plug-ins are used (yes I know, Questy is not enabled by default).

    MediaWiki cons

    * Annoyingly religious developer base who say things like “Why would you want to password protect anything against viewing?” Because I do. Now please answer why I can’t….
    * Crappy permissions structure which is simultaneously overly complex and underfunctional
    * Spam magnet — this is not 100% MW’s fault, but there you go
    * Everything accomplished through editing config files on server, which makes shared administration difficult

    I have to admit I like the culture of Dokuwiki better. I can barely stand to read the MediaWiki forums, where every request for a feature is met with a “You don’t understand what a wiki is” rant.

    I worry though that as wikis I’m involved with get bigger that Dokuwiki might start to drag — I just don’t see the examples of larger installation I’d like to see. I also don’t know what the quality of the developer community for Dokuwiki is — with MediaWiki I know I can tap the UBC guys, for example, on dev questions. Although if you guys are getting on board, that starts to tip the scale there.

    I guess I got to decide this this week. If I can get a more detailed Dokuwiki pitch from you that would be great. I see huge potential in wikis if we can rethink how we use them, but choosing the right platform is such a big piece of that….

  2. Reverend says:


    I think part of what has killed Wikis in education is there was only the one viable paltform, namely MediaWiki, and it has been extremely difficult to bring folks along fi we can;t get something as simple as a working visual editor. I like the fact that DokuWiki is a bit simpler, less overhead, and looks good. I will let Tim make the argument because he knows it better than me, but between the visual editor and spam reprieve–what else could you want? 🙂

    More seriosuly, I have no idea of how it would work under serious pressure, but from what I understand flat-file applications like DokuWIki are far less resource intensive, which may be a plus.

    Why not try it you may even start a revolution 🙂

  3. I agree – the weird puritanism of Wikipedia can be soul-deadening. I like how Dokuwiki is a nice middle space between the crime against humanity of Google Sites WYSIWYG and the visual colonic of MW. But a revolution needs comrades, so are you guys into this, or are you just playing?

    I’m dead serious about making a new wiki push focused on cross-course/cross-institutional collab. I tried the pitch on an audience at AAC&U last week, and I think it’s got legs.

  4. Reverend says:


    We are all in on DokuWIki, in fact that was what this was all about, getting off the MediaWiki bus. It was hard because of the work UBC has done, but we’re trying to do some of that in-house for DokuWIki right now. See this posts for some details:

    And to be clear, Ryan and Tim showed me the way, i was ready to hold out, but I am now a believer 😉

  5. Alan Levine says:

    I grow a bit weary of comparisons of tool attributes along, whether it is Pac/PC, drupal/wordpress, mediawiki/docuwiki/wedgie wiki…

    Yes at some point the feature/capability sets are important, but what is missing is the quality, level, skills of experience of the people using the tools. MediaWiki shines at UBC not wholly on what the software does, but because of the expertise of the team of Novak, et all there. DTLT has the group expertise in WordPress to make it do amazing things.

    So when we have these tool discussions, it becomes things like the people experienced at making drupal work well trying to out boast the group who put wordpress into top gear. I just do not put much stock in ruling the tools alone.

    That said, I have to say I agree with all y;all. It’s not whether one wiki software is better than the other, but what can you or your group do with it?

    That also said, I both love the idea of wikis but since the 1990s have to say nearly every wiki project has left me disappointed, and almost not at all because of the software. Without the zeal of a wiki gardener of the hordes of Wikipedians, they get messy, ugly, dead ended. They are mostly non-intuitive beyond a technical oriented audience, and again, unless a good number of participants have a “court sense” of the environment, they flounder.

    I expect there are hundreds of exceptions to my generalization, and there are obviously considerations as to what people do in the space, brilliant for open brainstorming.

    The success totally hinges on the widely variable human factor, not just feature sets. I remain open, and knowing DTLT is focusing on wikis hints me that there is potential.

    • Reverend says:

      I don’t disagree about the difficulty of wiki-specific projects, and have slammed my head against that wall a few times. This is why I kinda love the very specific use of the DokuWiki for documentation and synching with GitHub. This provides us the ability to focus on one small element, and at the same time experiment with sharing it. I’m a bit wary of tool arguments myself, even though they can be fun, but the reason we experimented with DokuWiki in the first lace was what the flat file system provided in terms of synching with GitHub. Which simply suggests the attention around GitHub, flat file applicatins, and more might be an interesting development this year—I almost feel it’s healthy given how WordPress specific much of our work has become. I don’t deny it’s been good to us, but I alos wonder what else there is.

  6. Tim Owens says:

    I certainly don’t disagree with Alan about whether wikis are even the right tool for the job or more of a comfort blanket for certain faculty. For documentation it’s absolutely the right tool for the job. And no doubt the level of support from colleagues both in your institution as well as the wider edutech community is certainly something to consider. But I can’t point my faculty to UBC’s folks. Hell, they don’t even fund the Wiki Gardener position anymore. Here’s what I know. Brand new wikis with the default settings are spam farms within 1 month of existence. It’s not an if, it’s a when. You can lock it down or you can try to use a variety of plugins (which are also a pain in the ass to install) and hope you get it, but it’s a moving target. Meanwhile our documentation has been in place since October with fully open editing turned on and *zero* spam edits so far. Maybe we’re lucky, or maybe the attention is not on that software right now. But either way that’s a data point.

    Things worth considering: Dokuwiki supports the same syntax as Mediawiki so there isn’t anything new to learn. Flat files scale far better than an overloaded database. Plugins are installed by pasting in the URL of the plugin and hitting the “install” button. No editing a php file through an FTP program to add code to a config file just to add a feature. The plugin architecture is very robust (which hints to me at the level of developer support). To me there are very few cons to using Dokuwiki right now and in fact they match many of the pros for MW so there’s far less to lose by switching.

    Bottom line is that Dokuwiki feels like something I can encourage a faculty member or student to use with a little support whereas most of the time I’m not even confident in my own ability to use and support Mediawiki (and I like to consider myself pretty confident in technology) and that’s a huge red flag.

  7. Alan Levine says:

    That’s extremely encouraging Tim, and I’m liking what I’m reading and seeing. The stuff you are doing there and on your blog are pushing new grounds.

    I frankly cannot recall one outstanding mediawiki use in my experience. Not many data points, but hey, that’s what we work from.

    The move to lean (database-less) connected tools is exciting. Kind of funny, my first wiki stuff was flat file ModWiki.

    DTLT out in front, that’s what we have come to expect, no sitting on past wins.

  8. Well, here you go, Jimbo:

    One of the best projects I worked on last semester with faculty was a dokuwiki wiki (on Reclaim, the Anth course, not the inclusion course), although unfortunately I couldn’t convince the faculty member to open it up. They had some valid concerns about shielding the students from outside trolling on some pretty sensitive issues they were covering, especially in the early stages. I think a lot of faculty would like a draft state for pages. I’m thinking this could be provided by killing the recent pages link and running search through Google, and then telling them to just not link up until they want it seen. But I’m guessing it’s not quite that simple.

    Wiki is only one prong of what I’m doing, but it seems like such a good fit for cross-disciplinary stuff I hope I can make it work.

    • Tim Owens says:

      If you haven’t already found it play around with the Access Control List Management area in Admin. You can setup namespaces or individual pages that wouldn’t be viewable to the public, only logged in users. They could be working on them and then later open them up for viewing if desired. Also possible to setup multiple roles for users (so maybe faculty have access to read and edit everything but students have a more limited role depending on needs, etc).

      I also recommend adding the htaccess rules to make the URLs pretty (because I’m all about the looks).

  9. Pingback: CSV to MYSQL to JS Filtered Table Tutorial | Bionic Teaching

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.