First: http://sourceforge.net/projects/cornucopt/
Yes, you can check out the tree.
Second: Powered By WordPress. I am working on the conversion details, which is why you are not reading this right now. (Note: WordPress is, regrettably, not recommended overall.)
Third: I’m pretty sure I fixed the softlink bug, but I have been so busy with points one and two that I have not actually checked. I still need something for the big-database problem, where all the miniscule little bug-fix changes get stored as full text, and I am reviewing other Wikis to see what they do. Understanding their code is difficult - hell, that’s half the reason I’m still coding this thing - so this is taking time.
July 4th, 2004
And now, an exciting new chapter in the young life of Cornucopt: nobody can log in and no pages will display.
Last night, I innocently added a bug to the bug list, and the database apparently chose exactly that moment to hit the space limit assigned to it by my ISP. The pages table is now evidently corrupted. I can still pull data out of the changes table, so I was able to rescue some data immediately for the project some friends and I were embarking on (and which probably created all the data that filled the drive).
At least, that’s my best guess as to what happened; I am far from a DBA. But man, that changes table got freakin’ huge.
I had implemented (and have implemented) no “small change” functionality in Cornucopt. In many wikis, you can designate an edit as a “small change” to the page, like a typo correction or a layout tweak, and it will store that change lumped in with the last change, rather than add a new entry in the DB and in Recent Changes, annoying everyone. Good feature, just hadn’t gotten around to it.
It’s relatively simple to add such a “small changes” feature. It needn’t present a security risk of sneaking in a huge change (either by marking it as small, or by doing it slowly).
But is it really what I need? Does it explain how a database table that contained every full version of every page on a small, new wiki got to be 200 megabytes? When the pages in question are about a K at most?
I may have to bite the bullet and limit the number of changes that Cornucopt stores, to something like the last 20. I feel like I’m letting future generations down. For right now, though, I’m investigating all these problems and how other wikis handle them. And, of course, getting my actual work done.
May 17th, 2004
Wicker is now Cornucopt.
Cornucopt is the language of the fictional land of Cornucopia, as described in the comic books of Dylan Horrocks. A cornucopia is also known as a horn of plenty. Cornucopt, née Wicker, will be a horn of plenty of language, a vessel made to increase the quantity and quality of that which flows through it.
I’m happy with this new name, which is actually an old name, although it took me a day or two to remember it. Besides increasing the pretension level of the whole project, it’s highly unlikely that anything else in open source will duplicate it. (Try it in Google.)
May 10th, 2004
Uh oh:
Wicker is a lightweight, modular Java application server, suitable for embedding in a web server, and intended as an alternative to the current standard of large-scale/monolithic application servers.
The project isn’t super-active, but still. “Application server” is close enough to what we do in the headspace of a comparatively tech-naive user that I am worried. Also, bigger projects than mine have had to change names due to conflicts with much smaller projects than themselves.
So if I had to call Wicker something else, what would I call it? WickerMan has come to mind, but it’s CamelCase, which ReallySucks, and it’s a bit… violent? So, suggestions more than welcome.
May 8th, 2004
I had a look at my referrer logs to see if anyone is really reading this… it’s hard to tell, all those hits could just be coming from my aggregator. I understand that some folks were trying to add something absurd to the Atom spec so they could prevent such problems and actually know who was reading their feeds. I’m gonna take the direct approach: if you’re reading, post a comment!
Anyway, the OO version of Wicker is now under private testing. Viewing pages works fine, and so (amazingly) does subclassing the basic Page class to do SoftlinkPages. The SoftlinkPage class isn’t perfect yet - I’ve decided to have them put “lastpage=XX” codes into URLs, instead of trying to read the referrer and parse out the page that called it. That will limit the creation of softlinks to only occur when you’re coming from another SoftlinkPage, but hey. It doesn’t have to be perfect.
What I’m working on now is a bug with logging in. It likes to forget who you are, instantly, between page loads, so something about the way the User class (which I’ve actually been using a while now, so I know it basically works) is getting toted around in the session has gotten borked. I hope this does not turn into another months-long stallout.
Once I have that worked out, I can go to work on seriously debugging Edit functionality. When the current feature set is fairly bug-free, I’m going to set about opening up the code under the GPL, likely on SourceForge unless they prove to be too hard to deal with compared to the competition.
I am surprisingly lucid for having had no protein today. (Watch, now that I’ve typed this I’ll start having dizzy spells.)
[Later that day: editing works! In fact, editing works better.]
May 7th, 2004
I finally unborked WickerTest so that SoftlinkPages no longer uniformly result in mysql urps. (Yes, I’m pretty sure that sentence was English.) I suspect I broke softlinks in the process, but at least you can do those nice things like reading and editing.
I’ve been looking around at alternative Wiki engines lately, because I always am, and learning from Tiki as well as from WTF, the appealingly contrived acronym (Wiki Type Framework) for a project that aimed to do something similar to what I’m doing with Wicker. Only different enough to be totally perplexing, and the project’s been dead for two years anyway, but yeah.
What I am saying, and what you are caring about oh yes you are, is that I’m going to retool Wicker’s innards to be all object-oriented and stuff. That way, one can create a new type of page by inheriting the qualities of another type and building on them. That will solve my current problem of having to have explicit hooks everywhere for everything a pagetype might want to do, which is unbelievably janky, whilst still keeping a pagetype’s code self-contained and neat. I know I am not using the word “whilst” properly.
As a consequence of this move, I will be using ops. URLs will have things like “op=edit” and “op=view” in them. This will make our URLs remind people of E2 that much more, which is kind of a mixed thing, but hey. Pagetypes will have but to override the function (on their parent pagetype) that corresponds to the op, to do something different. And a lot of other neat stuff.
This is one of those things where everything gets easier in the long run, but in the short run I have to rip everything to shreds and start again. So, who knows when I’ll be done, and in the meantime, let’s play Lexicon.
April 29th, 2004
So, TikiWiki. Yeah. Most insanely overdeveloped Wiki ever, but I’ve been surprised by my toy installation - I’ve been able to figure out how to do most things I want to do, quickly and easily. It even uses Smarty for templating, as Wicker does. What I haven’t done yet is look much at the Tiki code, but if that goes well, maybe I will just become a Tiki developer. Give them softlinks, give them dynamic blogs (an idea stolen from JSPWiki that would be fast to implement as a Wicker pagetype, although I’d likely call it something like a Topic… or just a Category, as it’d be an ideal way to do Wiki categories)… and give their CSS a few well-placed slaps on the backside.
But wow, do they ever have too many PHP files on the root level.
[Update: looks like they are fixing the latter problem, and some others, over here.]
April 19th, 2004
So: Wicker’s up, friends are signing up for accounts although mysteriously not goofing around and editing things, life is lovely. I decided to start writing Wicker’s first pagetype: a page with E2-style softlinks. From the very first draft of the very first script I wrote for Wicker, pagetypes were intended to be quite straightforward: if you see that a page has a type, include a script named after that type just before you display the page.
Obviously, I was destined, in the very first pagetype I wrote, to discover that I needed to touch more code than that. That, in fact, I needed to touch several scripts with special-cased code, just to do something incredibly simple.
I am so very, very lame compared to real coders.
But it’s okay, because really, the whole goal with Wicker right now is “make it work.” Not make it work fast, not make it work well, not even make it maintainable. Make it work, then consider it a prototype.
Then, once somebody who can actually code thinks Wicker might be good for something, I make them do the hard work! Yay!
March 26th, 2004
Soft launch ahoy!
http://www.gibberish.com/wicker/
Contact me if you’d like an account, with which you can make changes. All may read, and subscribe to the recent-changes RSS.
March 23rd, 2004
Because I’m dumb, I am thinking about pushing the panic button, and rewriting Wicker from the ground up in Python. Pretty much all of what I need is there: basic CGI crap, templating, database access, maybe even some user-management libraries that don’t suck. I am considering this move because Bob Galloway, known to all three people who experienced my brief flirtation with ecore as the Funk Queen of the Universe, is an experienced wikismith and ardent Python advocate. I could really use his help. Also, I have tried everything I can think of to eliminate the damned login bug and it is starting to look easier to just start the hell over. Thoughts?
January 15th, 2004
Next Posts
Previous Posts