Jacob Santos

Tasks I want to have done by the end of today or this weekend.

1. CherryPy server test – Started

   Involves a base controller for making sure that CherryPy is working correctly. Fairly simple to complete, however, I am attempting other tasks at the same time.

2. Installer / Upgrader – Not Started

   The installer must fail gracefully, if possible. Will install the initial tables for running the software.

   1. The installer must make sure that the python version is supported, in case the setup.py install wasn’t called first.
   2. The installer must ensure that dependencies are installed.
   3. The installer will check for existing trac.conf and ask if the user wants it converted.
   4. The installer will check for the database configuration script and attempt to create it checking for permissions before asking the user to create it. If it can’t create it, the installer will halt and the message informing the user to create the database configuration script will be output.
   5. The final parts will involve naming the initial project and setting the authentication details.
3. Plugin Support – Not Started

   Going to involve refactoring or rewriting what is contained in loader.py in the Trac source code. I’ll have to make sure that I attribute correctly any code that I copy. I’m probably going to attempt to rewrite the parts using the modules that exist already and if I have any problems going back to how trac works.

   The goal is to enable controller and theme support in plugins. So what this means is that I want to have some additional coding checking the modules for the presence of certain namespaces and files. The way I want themes to work is that the theme can replace any of the themes in the directory. If the plugin is standalone, then adds the controllers, then the views will simply be called by the plugin to use their own views along with the main theme layout files.

4. HMVC Controller – Not Started

   Well, I believe Trac is currently HMVC now, so nothing is gained in this part. What I’m doing is simply keeping that ability and forcing a default MVC for the core parts. I am going to test core parts as plugins. So the browser will be a plugin containing its own controllers, views and models. I also want to experiment with a blog plugin. I need to first make sure that this is even possible and simple. It has to be simple for plugins like the current Trac.

5. Use Mako for Templating
6. Use SQLAlchemy – Not Started

   Involves simply installing SQLAlchemy, checking for SQLAlchemyin the installer and using SQLAlchemy for the installer / upgrader models.

   There is an extension to SQLAlchemy that enables more of the ORM in SQLAlchemy, Elixir is the name, I believe. All plugins and core code will be transitioned to SQLAlchemy models. I keep wanting to enable plugins to install along with the core installer, but letting WordPress be my guide, I’m not thinking this is a good idea.

7. Authentication – Not Started

   This feature of course must be started initially for the administration to work. The problem is that this feature will involve a lot more than simply working with the web application. I want to have Facebook, Google, Yahoo, etc to the mix and allow bridges and plugins to extend the authentication list. This differs from the official Trac in that Trac only allows web server type authentication, which granted, is quite a lot and could be extended to include the above. There is too much invested in online technologies and custom authentication to be set aside. People understand Facebook and Google authentication, having used it for many of existing sites.

   The goal is to also make it easier for end users to use this project and experiment on whether it matters. However, I’m not going to be able to invest a lot of time extending the authentication to more than custom scheme in the database and implement a basic authorization policy for the software. Once the base is set, extending it in the core and plugins will be possible.

8. Administration – Optional, if time available

   The base administration will include basic project support based on the database scheme. This will include plugin and user management.

9. Navigation and JavaScript API – Optional, if time available

   I want to output JavaScript and navigation dynamically based on an API that will build the list for Navigation and JavaScript / CSS files and output them using a template call. The administration and front end will use both of these to ease development of plugins and extensions.

10. Setup.py – Not Started

    Of course, will enable installing Projile based on the setup tools in Python. I also want to extend the setup.py to include additional options for setting up the web installer and the conf script to ease the install tutorial as much as possible. I want to get the user on the web installer as fast as possible and most likely will require testing apache capabilities (if possible) and providing manual means as well.

    If all the person installing has to do is:

    python setup.py install
python setup.py config wsgi|fastcgi|etc PATH_TO_PUBLIC_HTDOCS

    Then I think I’ll be doing something right. This is relatively simple, while not as simple as perhaps PHP would be able to do. Well, why not? I think I might attempt to include a PHP installer that sets up Projile and if it works well enough, might include one for Trac in the future. The major issue will be permissions, but if it is allowed, then it should be a major boon in easing installation. I’m going to ignore the PHP component for now and focus on Python. Spending more than 15 minutes on the PHP solution probably wouldn’t be worth saving 15 minutes of initial setup of the project.

Future Notes

1. Wiki code

   The wiki is so ingrained into the current Trac that stripping it from the core would be absolutely not something that should be done. It is arguably one of the best features of Trac and the power of the code will have to be converted to this project. I envision the conversion simply moving the code to Python 3.2 where needed and refactoring the code to use Python 3.2 where acceptable.

   Whether or not there will be a specific wiki or a wiki as a plugin, I’ve yet to determine. The code will be there, of course, but whether the wiki can be removed or

2. “But Trac already does this!”

   I know that most of the so called features I’ll be adding are found in Trac now and I could simply code my changes as a plugin and be done with it. If the primary goal was simply to add the experimental features, I would do so as a plugin. To justify my decision, I will say that I’m doing this for educational purposes. Converting Trac to CherryPy, SQLAlchemy and Mako / Genshi, will allow me to be more familiar with those libraries and serves dual purposes of messing around with Trac and learning those libraries.

   Furthermore, hacking apart Trac forces me to go through the entire Trac source code enabling me to familiarize myself with the code base unlike I would have if I simply read through the code. To be honest, I have read through the code already and found parts that I passed over without much thought. Tearing apart and piecing back together does not make for a great initial project, but it does allow me to learn quicker and better understanding of the code I’m looking at.

3. Future blog feature

   I envision this simply being an aggregation of existing blogs or RSS feature. I might make it something more depending on the Page support I want to also add. This will never be a fully complete blogging feature like the one in WordPress.

4. The Goal

   The goal is to get to the point where I can use my new project instead of my blog for tracking features. Also moving to the point where I can copy the existing information over as well. In order do that, I’m thinking I need to track the time spent on each of these features in order to accurately test features.

Possibly Related Posts:

• Game Engine Development and Open Source
• Plans for Base CMS
• Project Plans
• Calibre Improvements Part 2
• Usability Testing Software Development