I was interested in Sycamore because it was based off of MoinMoin, but lately I’ve been interested in static files because of their simplicity and reliability. Therefore, I’ve taken an interest in MoinMoin. Its quite nice actually, so through that, I’ll likely get more exposure to the core of how Sycamore and Sycaless are powered by python.Already I’ve figured out how the wikifarm setup works, and I like it! That being said, I’ll probably restore multi-wiki support in a single database at some point. I liked how Wordpress used table prefixes to separate blogs, but after seeing how well MovableType deals with it, I’m leaning back towards a single database.

Since I first started working on Sycaless, I’ve learned a lot about Python. Between then and now, I’ve spent a lot of time working on Schematronic, a python powered web application engine, and so I’m really looking forward to getting things going with Sycaless again.

• python-tz
• python-psycoppg2

I’ve decided against using the model from Sycamore, which provided row-level separation of wikis with a wiki_id key. Thus, I removed all those columns and the accompanying code. I left it in for the memcache code, as I’ll probably replace the wiki_id with a domain key, so that there are no collisions in memcache for different wikis which are on different databases. Instead of the wiki_id key, I’ll instead opt for table prefixes. That seems to be a common strategy for hosting multiple instances of data sets within a single database. Works for me with Wordpress and MediaWiki.

I keep finding cool things about Sycamore which I didn’t know existed - like multiple wiki support with a single database and code base. I wonder if this is what a wiki farm is about? Oh well, although I believe that the way Sycamore had wiki farms setup would preserve your login across wikis, I prefer to let my browser save the login information for each domain separately, even if the credentials refer to the same (even identical) data object. That’s how I have my Wordpress blogs setup, and it actually works perfectly well. I’m trying to see if I can add another wiki by changing some of the settings in sycaless_config.py and running BuildDB.py. Nope:

_mysql_exceptions.OperationalError: (1050, "Table 'curPages' already exists")

I’m really excited to report that I’ve added a mod_wsgi interface to sycaless! That enabled me to remove the wsgi_server code from the code base, removing a lot of extra stuff. I’ve also removed optik (a command line library for python), which I’m not sure was used for anything. I tested out the maintenance.py script and it still works without optik.

The Sycamore default database has 38 tables, I removed the captcha table for sycaless so now it only has 37 tables. I’m also planning on removing the mapCategoryDefinitions, mapPointCategories, mapPoints, oldMapChanges, oldMapPointCategories, and oldMapPoints tables. I just removed the tables and sycaless still works, yay! There are two views I’d also like to remove: currentMapChanges and deletedMapChanges. Done, seems to still work! Now we’re down to 29 tables. :-)Speaking of map stuff, I’ve removed a lot of the code for map support in sycaless. Its not that I don’t think its a good idea, its just outside of my interest in the software.

I am very pleased with how the reduction of Sycamore into Sycaless is going. So far I’ve changed quite a bit and am getting the feeling that it will be much easier to manage now. Granted, a lot of the nice functionality that Sycamore has is no longer present, but personally I’m not interested in the bells and whistles. I prefer a solid core that is reliable and flexible.

It appears that Sycamore relies on javascript and cookies, and I ran into an issue with this and domains. I ended up removing the domain part of the cookie settings. One very cool thing about Sycaless is that it stores uploaded files in the database as binary data. That is something I wasn’t a big fan of back in the day, but since then I’ve become more comfortable with it. I’d probably only use the database for very small files at this point.

I’m tracing back a request to understand how Sycamore more or less works. The index.fcgi file which I’m loading via Apache connects the Sycamore/request.py to the Sycamore/support/wsgi_server.py. When I first setup sycaless, I fished around in request.py, and I think it might be possible to simply connect apache to Sycamore/request.py, and remove the wsgi_server.py. At any rate, I believe that request.py is the gateway to the Sycamore application in general.