1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
|
PyBlosxom TODO
==============
VERSION = $Revision: 1067 $
This is a really high-level todo list. Nothing here is written
in stone--this is mostly just a collection of thoughts. As such, not
everything in here will make sense to implement. Each item really
needs fleshing out before decisions on implementation should be made.
Before launching into anything, check the SVN repository which has
the latest version of this TODO list.
If you're inspired by any of these tasks, let us know on the
pyblosxom-devel mailing list.
If there are items not mentioned here, let us know on the
pyblosxom-devel mailing list.
Thanks!
MILESTONE VERSION 1.4
=====================
Prospective release date: February sometime (ha!).
UNIT TESTING
- Look at the Cheesecake system and use something similar so that we
have some basic tests we can run that test the whole system.
MANUAL
- Go through and fill in more FIXMEs.
- Need to add installation instructions for PyBlosxom as WSGI middleware.
- Convert to reST.
PYBLCMD
- Finish up pyblcmd so that it's a good alternative to running
pyblosxom.cgi.
ANYTHING ELSE?
- Paste support.
PROJECT INFRASTRUCTURE
======================
UNIT TESTING
- We need additional unit and functional tests. Part of the testing
framework is in as of PyBlosxom 1.4. This needs to be fleshed out.
MANUAL
- Go through and clarify the config.py properties if we haven't already
and provide examples in the PyBlosxom Manual.
- Need to take out a lot of the blah blah blah content and clean up
the language so it's clearer with more examples. Also look at trimming
text if possible.
- Need to add installation instructions for PyBlosxom with SCGI/FCGI with
flup.
- Need to add installation instructions for PyBlosxom for IIS.
- Need to add information on migrating entries from other blog systems
(Drupal? WordPress? LiveJournal? ...) to PyBlosxom.
- Add instructions for PyBlosxom with FastCGI.
- Add instructions for servers with multiple users (look at Martin Kraaft's
stuff).
PYBLOSXOM
=========
DATA CACHING
- build a global caching mechanism that dumps old data? look at
memcache?
CONFIGURATION DEFAULTS
- Defaults for config.py variables need to be centralized somewhere,
copied, and then updated with whatever is in config.py. This should
be done instead of get defaults floating across the codebase.
- We should look into setting defaults to sane values allowing PyBlosxom
to run with no config.py file at all.
PATH AND ABSOLUTE PATH
- For each entry, we calculate $path and $absolute_path. Why do
we have both of them? Are there inherent differences between the
two? What does blosxom do?
Regardless, it looks like $path behaves differently in 1.3 than
in previous versions.
WINDOWS
- Does PyBlosxom currently work in Windows?
MAC OSX
- Does PyBlosxom currently work in Mac OSX?
PYTHON VERSIONS
- Which versions of Python do PyBlosxom work in?
CONFIGURATION
- The Debian package (it might not do this anymore) assumes that
config.py is a site-wide configuration file rather than a user-specific
configuration file. MoinMoin has both a site-wide configuration file
and a user-specific (well... wiki-specific) configuration file.
Need to look into how they did their stuff and look into changing our
configuration system to do something similar.
MTIMES
- pyblcmd should go through the datadir and export the mtimes for
all files (by calling cb_filestat) into a file index
(There's an rdate module that copies mtimes into the entries. We
might want to fold this functionality into pyblcmd.)
- adjust pyblosxom so that it looks for the file index cache before
the default of stating the file
TEMPLATES
- Flavours are specific to the blosxom rendering engine that PyBlosxom
has. It's about time we add other rendering engines. For example,
Myghty, Cheetah, ... This might make it easier/more-useful for
using PyBlosxom inside of a TurboGears or a Pylons application.
FLAVOUR FILES
- We still have one problem with making flavour files easy to use and
install: resources. If a flavour file requires a .css file or images
or something like that, it needs to be handled outside of PyBlosxom
by the web-server. That makes documentation a mild pain in the ass
and makes it harder to explain in a generic sense how to install
flavour files. It'd be cool if there was a way to specify whether
a given resource belonged to a specific flavour and if so allow
PyBlosxom to serve that resource (with the correct mime-type) from
the flavour's flavour directory.
I18N
- Are we internationalization friendly? I think parts of the PyBlosxom
system are, but we've got an awful lot of English strings in there.
We should look at Internationalizing the error messages and other
messages as well. This might include internationalizing the flavour
files--but I'm not entirely sure how that would work.
TAGS
- There are a series of tags/folksonomy kinds of plugins now. All of
these (at least, last time I looked) suffer the problem that tags
get stored inside the entry file and we don't open up and read the
entry file until after we know we're going to render it.
- This might be something we want to address inside of PyBlosxom.
STORAGE
- Walk is less than optimal. We should probably split it into a couple
of different functions with hooks allowing for other data persistence
methods. This should make the API easier to use in regards to entries
and it'll allow us to optimize the functions using caching more easily.
- how many plugins use Walk? for what purposes?
|
