<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">

  <title>Sycaless</title>
  <link href="http://www.sycaless.docunext.com/blog//atom.xml" rel="self"/>
  <link href="http://www.sycaless.docunext.com/blog//"/>
  <updated>2011-10-04T19:50:57-04:00</updated>
  <id>http://www.sycaless.docunext.com/blog//</id>
  <author>
    <name>Your Name</name>
    
  </author>

  
  <entry>
    <title>MoinMoin</title>
    <link href="http://www.sycaless.docunext.com/blog//2008/08/moinmoin.html"/>
    <updated>2008-08-18T15:32:51-04:00</updated>
    <id>http://www.sycaless.docunext.com/blog//2008/08/moinmoin</id>
    <content type="html">&lt;p&gt;I was interested in Sycamore because it was based off of &lt;a href=&quot;http://www.docunext.com/wiki/MoinMoin&quot;&gt;MoinMoin&lt;/a&gt;, but lately I&amp;#8217;ve been interested in static files because of their simplicity and reliability. Therefore, I&amp;#8217;ve taken an interest in MoinMoin. Its quite nice actually, so through that, I&amp;#8217;ll likely get more exposure to the core of how &lt;a href=&quot;http://www.docunext.com/wiki/Sycamore&quot;&gt;Sycamore&lt;/a&gt; and Sycaless are powered by python.Already I&amp;#8217;ve figured out how the wikifarm setup works, and I like it! That being said, I&amp;#8217;ll probably restore multi-wiki support in a single database at some point. I liked how &lt;a href=&quot;http://www.docunext.com/wiki/Wordpress&quot;&gt;Wordpress&lt;/a&gt; used table prefixes to separate blogs, but after seeing how well &lt;a href=&quot;http://www.docunext.com/wiki/Movable_Type&quot;&gt;MovableType&lt;/a&gt; deals with it, I&amp;#8217;m leaning back towards a single database.&lt;/p&gt;
</content>
  </entry>
  
  <entry>
    <title>Python Education</title>
    <link href="http://www.sycaless.docunext.com/blog//2008/07/python-education.html"/>
    <updated>2008-07-18T21:53:02-04:00</updated>
    <id>http://www.sycaless.docunext.com/blog//2008/07/python-education</id>
    <content type="html">&lt;p&gt;Since I first started working on Sycaless, I&amp;#8217;ve learned a lot about Python. Between then and now, I&amp;#8217;ve spent a lot of time working on &lt;a href=&quot;http://www.schematronic.com/blog/&quot;&gt;Schematronic, a python powered web application engine,&lt;/a&gt; and so I&amp;#8217;m really looking forward to getting things going with Sycaless again.&lt;/p&gt;
</content>
  </entry>
  
  <entry>
    <title>Dependencies</title>
    <link href="http://www.sycaless.docunext.com/blog//2008/03/dependencies.html"/>
    <updated>2008-03-11T08:04:49-04:00</updated>
    <id>http://www.sycaless.docunext.com/blog//2008/03/dependencies</id>
    <content type="html">&lt;ul&gt;
&lt;li&gt;python-tz&lt;/li&gt;
&lt;li&gt;python-psycoppg2&lt;/li&gt;
&lt;/ul&gt;

</content>
  </entry>
  
  <entry>
    <title>Single Wiki</title>
    <link href="http://www.sycaless.docunext.com/blog//2008/01/single-wiki.html"/>
    <updated>2008-01-22T10:54:19-05:00</updated>
    <id>http://www.sycaless.docunext.com/blog//2008/01/single-wiki</id>
    <content type="html">&lt;p&gt;I&amp;#8217;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&amp;#8217;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&amp;#8217;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.&lt;/p&gt;
</content>
  </entry>
  
  <entry>
    <title>Multiple Sycaless Wikis</title>
    <link href="http://www.sycaless.docunext.com/blog//2008/01/multiple-sycaless-wikis.html"/>
    <updated>2008-01-21T14:47:06-05:00</updated>
    <id>http://www.sycaless.docunext.com/blog//2008/01/multiple-sycaless-wikis</id>
    <content type="html">&lt;p&gt;I keep finding cool things about Sycamore which I didn&amp;#8217;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&amp;#8217;s how I have my Wordpress blogs setup, and it actually works perfectly well. I&amp;#8217;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: &lt;pre&gt;&lt;code&gt;_mysql_exceptions.OperationalError: (1050, &quot;Table &#8216;curPages&#8217; already exists&quot;)&lt;/code&gt;&lt;/pre&gt;I&amp;#8217;m a little confused though, how can I create another wiki_id?&lt;/p&gt;
</content>
  </entry>
  
  <entry>
    <title>mod_wsgi</title>
    <link href="http://www.sycaless.docunext.com/blog//2008/01/mod-wsgi.html"/>
    <updated>2008-01-21T11:36:03-05:00</updated>
    <id>http://www.sycaless.docunext.com/blog//2008/01/mod-wsgi</id>
    <content type="html">&lt;p&gt;I&amp;#8217;m really excited to report that I&amp;#8217;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&amp;#8217;ve also removed optik (a command line library for python), which I&amp;#8217;m not sure was used for anything. I tested out the maintenance.py script and it still works without optik.&lt;/p&gt;
</content>
  </entry>
  
  <entry>
    <title>Database Tables and Map Stuff</title>
    <link href="http://www.sycaless.docunext.com/blog//2008/01/database.html"/>
    <updated>2008-01-21T10:29:29-05:00</updated>
    <id>http://www.sycaless.docunext.com/blog//2008/01/database</id>
    <content type="html">&lt;p&gt;The Sycamore default database has 38 tables, I removed the captcha table for sycaless so now it only has 37 tables. I&amp;#8217;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&amp;#8217;d also like to remove: currentMapChanges and deletedMapChanges. Done, seems to still work! Now we&amp;#8217;re down to 29 tables. :-)Speaking of map stuff, I&amp;#8217;ve removed a lot of the code for map support in sycaless. Its not that I don&amp;#8217;t think its a good idea, its just outside of my interest in the software.&lt;/p&gt;
</content>
  </entry>
  
  <entry>
    <title>Nice Progress</title>
    <link href="http://www.sycaless.docunext.com/blog//2008/01/nice-progress.html"/>
    <updated>2008-01-20T20:39:15-05:00</updated>
    <id>http://www.sycaless.docunext.com/blog//2008/01/nice-progress</id>
    <content type="html">&lt;p&gt;I am very pleased with how the reduction of Sycamore into Sycaless is going. So far I&amp;#8217;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&amp;#8217;m not interested in the bells and whistles. I prefer a solid core that is reliable and flexible.&lt;/p&gt;
</content>
  </entry>
  
  <entry>
    <title>Cookies + Javascript + Images</title>
    <link href="http://www.sycaless.docunext.com/blog//2008/01/cookies-javascript.html"/>
    <updated>2008-01-20T17:14:19-05:00</updated>
    <id>http://www.sycaless.docunext.com/blog//2008/01/cookies-javascript</id>
    <content type="html">&lt;p&gt;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&amp;#8217;t a big fan of back in the day, but since then I&amp;#8217;ve become more comfortable with it. I&amp;#8217;d probably only use the database for very small files at this point.&lt;/p&gt;
</content>
  </entry>
  
  <entry>
    <title>Tracing Back</title>
    <link href="http://www.sycaless.docunext.com/blog//2008/01/tracing-back.html"/>
    <updated>2008-01-19T16:27:40-05:00</updated>
    <id>http://www.sycaless.docunext.com/blog//2008/01/tracing-back</id>
    <content type="html">&lt;p&gt;I&amp;#8217;m tracing back a request to understand how Sycamore more or less works. The index.fcgi file which I&amp;#8217;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.&lt;/p&gt;
</content>
  </entry>
  
  <entry>
    <title>Sycaless Installed</title>
    <link href="http://www.sycaless.docunext.com/blog//2008/01/sycaless-installed.html"/>
    <updated>2008-01-19T14:21:03-05:00</updated>
    <id>http://www.sycaless.docunext.com/blog//2008/01/sycaless-installed</id>
    <content type="html">&lt;p&gt;I&amp;#8217;ve managed to get sycaless installed on a development machine! Woo-hoo. :-)I think the subversion trunk I checked out might have been unstable as I had to track down a bunch of odd bugs, but I did eventually get the wiki running again. There is still a lot I&amp;#8217;m not interested in so I&amp;#8217;m going to continue removing more stuff for now, and then I&amp;#8217;ll get an idea of how everything is setup and what I like and don&amp;#8217;t like about the architecture and design. One of the bugs I wrestled with was due to ampersands in query strings used to serve files. I don&amp;#8217;t know why on earth developers continue to create web servers on top of web servers! It opens up so many problems for a pretty simple task in itself. The most obvious security risk being that someone would put in an alternate path to a private file, and if the security settings on the system aren&amp;#8217;t correct, it could be a gaping hole. Although it appears that sycamore doesn&amp;#8217;t suffer from this entirely, it is definitely something I&amp;#8217;m going to remove. I realize many web developers are using interpreted languages like python, ruby and php to build web servers and web applications in one, but I&amp;#8217;m not buying into that. I prefer to use Apache 2 with FastCGI and am warming up to mod_wsgi with python.&lt;/p&gt;
</content>
  </entry>
  
  <entry>
    <title>Sycaless</title>
    <link href="http://www.sycaless.docunext.com/blog//2008/01/sycaless.html"/>
    <updated>2008-01-18T23:45:33-05:00</updated>
    <id>http://www.sycaless.docunext.com/blog//2008/01/sycaless</id>
    <content type="html">&lt;p&gt;Sycaless is a personal fork of the Sycamore project that I can pick apart as a learning project to understand how it works better, as well as learn more about python. If you are interested in sycaless, I&amp;#8217;d instead recommend checking out sycamore instead for now.&lt;/p&gt;
</content>
  </entry>
  
</feed>

