I've attempted to build (compile) on Snow Leopard with the following result (using Python 2.6):

rnm-macpro(809)wfdr: ./compile 
Traceback (most recent call last):
  File "./compile", line 5, in <module>
    import argparse
ImportError: No module named argparse

And also on CentOS 5.5 (using Python 2.4.3):

v04(1006)wfdr: ./compile 
  File "./compile", line 34
    extrapad = " " if paddinglen % 2 else ""
                    ^
SyntaxError: invalid syntax

As it stands currently, both TinyMCE and jQuery are in the base install of the framework, as some of the modules make use of their functionality. For jQuery, this is not much of an issue, as it is only one reasonably small file, and is commonly used. However, TinyMCE is (ironically) huge, and is used much less frequently. Regardless, these frameworks probably don't belong in a base install of the framework, and should be installable by some other means. Not sure what to do about things like this. How do other frameworks deal with this issue?

There is very little to no documentation about the various aspects of this framework available to the public. However, there is still quite a bit of internal documentation that could be released to the public, bearing a way to convert google docs stuff into a format that github recognizes, and someone with access willing to spend time to remove branding and such.

Much of even that documentation is outdated, so I'll have to go write some more up when I get a chance (before adding features :P).

We might want to switch from https://github.com/fduraffourg/go-openid to https://github.com/hokapoka/goauth, as the latter seems to be much more commonly used. However, neither of them seems to be maintained, so we might just have to fork one of them and use the fork...

Running wfdr recompile all will not exit on the first module that fails with a nonzero exit status. This is problematic because it means that errors are not immediately obvious or as obvious as they should be.

This issue has been bugging me for some time- the base/ and mobile/ directories within all of the module asset folders (css/, img/, js/, etc) are awkward to work with, and don't really add much in terms of usefulness. Having to navigate an extra directory level should not be required, and adding layout customizations after one of the application versions is developed should be easier. Additionally, created files should be sorted by name then layout by existing user tools.

The best solution to this problem that I can think of is to name css, js, and template files according to the conventions in the go tree for conditional file inclusions. If you name a file foobar_linux.go, it will only be compiled into the package if the target system is Linux. We could do something similar, although our filter criteria will be different. foobar.css would always be included, foobar_mobile.css would only be included for mobile clients, and foobar_desktop.css would only be included for desktop clients.

Changing this behavior will require essentially rewriting wfdr-cache-monitor and some of the surrounding scripts. Who knows- perhaps we might get a nicer codebase (the current logic for wfdr-cache-monitor is somewhat convoluted and confusing, despite several rewrites).

The base module right now uses an entirely homebrew solution (based on go) in order to achieve the effect of a reverse http proxy. Although it works reasonably well and is fairly reliable, the lack of optimization in both it and the go http methods that it uses means that under heavy loads it will use just as much (or even more!) CPU than the actual modules. A vanilla nginx and plugin-- or, if necessary, a fork/patch--should do the job much more efficiently. However, this not a particularly easy task, and it's not particularly important to the framework in this development stage, so this issue is low priority. Someone can feel free to take this on if they actually want to use this somewhere in production, or are more familiar with nginx.

Due to hard-coded listening ports in each of the modules, it's very possible that two modules could end up listening on the same port. The framework should solve this by automatically assigning ports to modules, either by making a config file in each jail upon start like this:

# Automatically generated module config file
port=:8081 # One possibility
listenon=localhost:8081 # Another possibility

Or, alternatively, by passing it as a -port=":8081" command-line argument. Not sure which solution is best at this point.

On my machine, at least, occasionally the wfdr command will panic somewhere in the rpc library when attempting to communicate with the daemon. As far as I know, this is not a bug in the program, but might be a result of using pipes.

This is not a critical issue, as the crashes are rare, and re-running the command will (almost) always fix the problem. Something certainly worth looking into, however. This does not crash the daemon.

The framework right now has lots of libraries that really don't necessarily belong with the framework, but are there as remnants of this being an internal project that started before the days of goinstall. All of the libraries that are not central to the framework should probably be moved to separate repositories if they would be useful on their own, or removed if they are no longer useful.