No, for reals this time. A roadmap. A plan of attack, perhaps.
0.1 - Basic admin pages, shields up, small change (prevents change from showing in recent changes), SoftlinkPage
0.2 - Better pagetype implementation, permissions, wikified templates
0.3 - Better admin pages, PageCollection/hierarchy (inc. CommentPage), more RSS/atom
0.4 - Weblog pagetypes, tags/CategoryPage? (Are categories a pagetype? Dunno, I’ll have to play with it. Tags and categories will probably require the same tech as what I’ve been calling a “DynaBlog,” a page that lists out the ten most recent results of some kind of search.)
0.5 - Kept page policy, better small-change, better install, … other
Out further than that are user groups, stupid email tricks (like Jot’s magic appending to a page), and even stupider API tricks, as well as all of the possible freaky magic I alluded to in the last post. And hopefully along the way we will be making things generally less buggy, more secure, etc.
Timeframes for all this? Shut up.
October 29th, 2004
Because I’ve promised my November free time to another project, I’m going to see if I can’t get an 0.1 release of Cornucopt onto SourceForge by the 31st. That means enabling user bans and page locks (and maaaaybe IP bans but likely not), and killing that one login bug. Seems possibly doable over the weekend.
But what I’m really here to write about is something else. I’ve been thinking some more about this wikified-templates thing, and how it could lead to what you might call “third generation” wikihood.
I have, floating around in this humid little brain of mine, some thoughts as to how pagetypes are going to have to change in the near future. It turns out that, as lovely as the object-oriented model is for me to write, it’s a bit confining. A new pagetype can, as far as I know, only inherit the behaviors of one parent class in PHP 4. (Heh - you might call it a strict-father model.) So, for instance, if I wanted to add functionality to the basic Page class that added Flickr-esque tags, but I also wanted to have tags on SoftlinkPages, I would have to duplicate the tag code, unless I’m mistaken.
I’ve decided to regress, if that’s the word, to the “plug-in” model favored by packages like WordPress and Movable Type. Instead of subclassing all of the Page code and modifying or extending it, most pagetypes will just be a bunch of functions that get called when a page of the right type does its regular Page thing. This may be easier for many developers to understand.
It also opens another door: that of actually having the PHP code that makes a pagetype work… (deep breath) reside in the wiki.
Obviously, you will not want to give just anyone access to a wiki page that gets executed as PHP code. This action on my part will raise the stakes on hard security a great deal; if there’s some hole in my code that lets people fake admin access, or whatever other kind of access that has the permission to create and modify templates, then people could inject PHP code that wipes the database, destroys files on the host computer, infects the host computer with viruses, and just generally kills kittens. Yikes.
But, he said while wiping his brow, think of the upside. Imagine if extending a wiki’s functionality were as simple as clicking ‘create new page’ and selecting the ‘pagetype’ pagetype. That’s what JotSpot is after, although they are taking the (frankly much more sane) approach of a vaguely programmatic markup language. It may be that I eventually decide that I am smart enough to take that approach, or I may build some kind of extra frippery that makes editing pagetype scripts take longer, or restrains it otherwise. Or I may just give people enough rope to hang themselves; what do I care?
I really want to find a way to do this. This is HyperCard reborn, this is a revolution in waiting. I have no reason to expect that I will get there first or at all, but promise like that is the reason I write code.
I am sounding a little wild-eyed and need to be more clear about how this all follows logically from wikified templates, and about how pagetypes, pagevars and templates would fit together in this model. Watch this space.
October 27th, 2004
On the subject of what sorts of parts of the rest of the net might be useful to wikis, Corny, or both: social networking systems.
Not the ones we know and loathe today, mind you. Systems like Friendster, Orkut, LinkedIn, MySpace, Tribe.net and on and on all have inflated opinions of their own utility, and most are closed to outside use anyway. They don’t even make good use of the rest of the net themselves; they’re walled gardens.
No, the social networking systems I’m interested in 1) haven’t been built yet, and 2) will have, in true small-pieces-loosely-joined fashion, deliberately low utility by themselves. (In fact, the ones that are trying to have even a little bit more usefulness are only drawing fire for it.)
I’m thinking that external semantic social networks could help wikis form a kind of “firm security” as an alternative to hard security, keeping some of hard security’s strengths over soft, while eliminating some of its weaknesses. See, social networks are useful at validating a self-asserted identity. How do I know you’re you? Because all the people you know say that you are.
That concept alone is far from perfect, but it’s also far from as bad as you might think. Have a look at LOAF, which describes itself as an “extension to email that lets you append your entire address book to outgoing mail message[s] without compromising your privacy,” so that “[c]orrespondents can use this information to prioritize their mail.” Random email sent from someone who knows a friend of yours, as evidenced by that friend’s presence in their address book, might be more trustable than random email from someone unknown. There are holes in LOAF as currently implemented, but the general idea is pretty intriguing. Merge it with cell phones, and the Bluetooth capability thereof, and it might get hot in here indeed.
Building such a system as part of a given wiki engine would be missing the point, in my view; the point is small pieces, loosely joined. Let someone else build a general-purpose system of some sort, then don’t be so much of a not-invented-here Wiki snob that you don’t take advantage. That’s the future.
October 27th, 2004
And wikified templates! JotSpot has inspired me to move Cornucopt’s HTML templates (the HTML files, with wacky stuff written into them, that take raw CoCo-generated data and make them into web pages, via a package called Smarty) inside of Cornucopt itself, such that mere users might be able to write their own. (And such that the templates get the advantages of wiki, like a version history, et cetera.) Combined with pagevars and a helping of what B.A. Baracus would call “jazz,” this could get us almost all the functionality of JotSpot’s forms and searches. Right now, Cornucopt’s templates live in separate files, in a little folder called ‘templates’ in the CoCo file tree. This is much handier for my current purposes than having to edit them in a browser, which is why this change isn’t scheduled for a while.
Will there be security headaches? Well, you have to really trust users to let them write arbitrary HTML. JavaScript is harmful to children and other living things. IFRAMEs are just as bad if not worse. Those are the easy ones; determining exactly what subset of HTML users really need to build applications will take some thinking. Also, the searching thing really is half the battle - I may need to implement XPath the way JotSpot does to allow people to select the pages they need to. Allowing people to create pages that create other pages could get hairy, essentially becoming a flooding attack. So I’ll have to design that carefully.
Just taking the templates into the wiki is not so difficult compared to the rest of the picture. I should really make a detailed roadmap. That was kind of a non sequitur. I want to be able to do a cartwheel.
October 15th, 2004
Dammit.
Although it looks like they don’t really do customization of the overall look of the page, plus they put script in the wiki pages, which always kinda gives me a rash. I mean, I guess they have some means of keeping non-admin users from accidentally hacking the script out, or they’re aimed at intranets and they don’t care. Also they seem to cost money.
From the beginning I have been aiming Cornucopt’s app-building features with the target of admins, not users, in mind. That is, the idea has always been that the human who sets up the server will know enough PHP to hurt himself set up the ways in which information will flow, and then other users will work within that. Maybe JotSpot’s approach is better, if they have a user-perms model that’s clean and easy. We shall see.
October 6th, 2004
I’ll start this (long!) post with a dirty little secret: I’ve never really been an active user of any large wiki. The closest I’ve come is having been very active on Everything2. E2 is not really much like a wiki at all, but one thing it makes a big point of, and that it does still have in common with the Wiki Way, is its status as a kind of microcosm of the larger Internet. You can’t link outside of E2 in an E2 writeup; you can type in a URL but it won’t be hot. E2’s interface affords a lot of inlinks, and its culture and original mission statement encourage users to make a lot of internal resources rather than utilize resources at other sites. If you want to link to HyperCard, for example, you throw some square brackets and link to E2’s node on HyperCard, not the more complete page on Wikipedia. The rationale is that if you want to link to a better page on HyperCard, you (or the community in general) should make a better writeup on E2 rather than taking energy off the site.
(more…)
September 14th, 2004
I’m just going to do a little recreational sketching of the next major things to go into Corny, because I’m thinking about it, because friends are starting to suggest that they really could use it, and… hey, even though programming little spaceships is more fun than programming text fields, that doesn’t mean that programming anything is more fun than dreaming up features. So let’s go!
Permissions. I have a few bones’ worth of the skeleton of this already. The challenge is how to do the UI. I have some decent ideas on that too, but: basically, the default Cornucopt install will let the user who creates a new page not just decide what type of page it is, but decide who can use it. If the pagetype says they can choose. And if they can create the pagetype in the first place. It is all both saner and more complicated than I am letting on. Sigh.
Usergroups. A big part of what will make permissions usable is the usergroup pagetype, one of the first built-in pagetypes that will really abuse the whole concept of “type of page” (and by no means the last). By default, Cornucopt will let anybody make a group of users, and add any users to groups they’ve made. It will not do anything asinine like let you send them all messages. Usergroups will be fairly simple to start, with no real messaging at all; they’re just a way to aggregate a bunch of names when you’re writing permissions.
Admin pages. You will need ways to change all this stuff even after you’ve done it. Not all of those ways should go right onto the edit page. I already wanted to have admin pages in 0.1, but I was thinking more of the sitewide admin stuff… you know, the stuff for… admins.
Because I am dumb, I am thinking about doing these before I do these. But what I really, really need is a coding partner. Please, people; I know PHP is the language of peasants and madmen, but think of the glittering prizes. Or the menus.
September 2nd, 2004
I feel particularly guilty for having these thoughts after finally getting Corny up on SourceForge. But: does this project still matter? To me, or anyone else?
It is not an exaggeration, or a negative statement in my view, to say that when Cornucopt is 1.0, the world will not care. I had a professor who, late in the thesis process for us senior art majors, did something I thought was brave and necessary. He told us all, “This stuff doesn’t change the world. It just doesn’t.” (Wait, actually I’m remembering that line from a Steve Jobs interview in Wired. So, as far as my art prof, I’m paraphrasing, but he did say the following:) “I remember the opening of my first gallery show in the city, in this tiny gallery. I had been sort of expecting the world to beat a path to my stuff as soon as the doors opened. And when nobody came into the gallery for half an hour I actually stormed down the stairs and out into the street, like I was looking for these people. Like I was gonna go and physically drag someone in. And it dawned on me that the world really just isn’t going to notice. I had to find a way to keep doing it anyway.”
Over the years, he did get noticed… just not by the world. And he built a career. But getting there has to be about something else. It is okay to want to get noticed, even to point yourself in that direction, but you have to know that it’s going to come slowly if it comes at all. And you have to build that into your approach. Successful projects in Corny’s vein (aimed at the overlap between geeks and non-, server-based, and having something to do with moving text around and onto a website) have been built out of that classic programmer’s need to “scratch an itch,” or out of passion. (Is there a difference?)
Whether Cornucopt will ever take off is unimportant to me (right now). The question that matters more is, do I still want this code badly enough? Why do I want to have a wiki with weblogs, or anything else I dream up, floating around in it?
I only have room for one programming project in my life at a time (not counting those I get paid to do). Right now, another one is calling my name again. I think I’m going to let Cornucopt cool for a while and see what happens when I want to come back.
Sorry to keep whipsawing like this. Yes, that’s a word.
August 3rd, 2004
As always, the more you do, the more there is to do. I have, technically, added “this is a small change” to Cornucopt as of yesterday; I was happily implementing all this stuff where the small change would overwrite the previous change, as long as the previous change was made by the same user. But I hit some sort of wall. The code was done, it looked like it’d work and everything… I don’t remember if it was thinking about the Recent Changes RSS that did it to me (I hate it when posts change slightly and my aggregator decides to tell me about them all over again!), or my doubts over what really caused the database explosion of a couple months ago, or what. I was just seized by dread and had to rewrite it.
So now all it does is keep your change out of Recent Changes. The non-bloat of the database will have to be the responsibility of a Kept Pages policy. That MeatballWiki link is an interesting read, but the concept can be a little tough to grasp. I’ll quote the salient bit:
We chose to version everything, but only keep revisions around for a limited timespan, say a week or a month. That is, destroy all revisions older than the timespan. The timespan will naturally depend on the amount of traffic to a site, the slower the traffic, the higher the timespan.
This scheme is not sufficient, though, as an attacker can destroy a page that hasn’t been touched in several months by merely editing it. After all, all its prior versions have been automatically erased, leaving you with only the latest, vandalized version.
Consequently, we add a little twist: timestamp the revisions not when they are created but when they are replaced. So, the current version of the page is not in the revision history, but when I make a change, the current version gets timestamped then and entered into the history. Then the new edit becomes the current version. […]
Equivalently, and more simply, you keep all previous revisions created during the timespan, plus one more.
That last sentence probably hews closest to how I’ll actually be coding it. But who the hell cares how I’ll actually be coding it.
Anyway. This policy seems the best compromise between posterity, security and efficiency. But it made me think of a lot of other things that are pretty important to have, which I haven’t worked on yet:
- IP banning (I have some GPL code pretty much ready to go for this, but there need to be admin pages to let you cope with it)
- Edit throttling (this is different from “shields up,” when you don’t take any edits at all - this is when one dork is flooding you with edits and you’d like to cool him off. Ideally you should be able to throttle individual users or IPs.)
- The fact that some users are going to want to keep every version of everything, which reopens the possibility that, to save bits, I should store things as diffs rather than full text, which reopens that technical can of worms
- Maybe I should just store small changes as diffs? I’d need to teach Version History and whatever I build to look at all changes to a page how to cope with diffs, but I think that’s it.
I also suspect there are more login bugs. I really don’t like those.
July 21st, 2004
0.1 milestone things we want/need:
- Admin pages
- “shields up” functionality
- “small change” functionality
- verified installability out of CVS/no major bork-ups
Then we will maybe even get fancy and release a files package on sourceforge.
Oh yeah: and I would like to verify that softlinks work. They will be our first big-pimpin’ feature, the kind that lets people know we are not their father’s Oldsmobile.
July 8th, 2004
Next Posts
Previous Posts