Re: filestat - a different perspective

(Sorry if this gets posted twice, after sending I saw that I sent this 
message via a different email address than I was subscribed to the 
list. So I am sending it again.)

Will and everyone,

Over the last nine months I have been toying with various blogging 
systems and I keep coming back to pyblosxom. I like the information 
architecture of blosxom sites, and python is my preferred language. I 
also like the portability of blosxom-style sites, both in moving 
between servers, and between blosxom implementations. The basic file 
format and is plain text, and we can easily move between various 
blosxom implementations.

To me, blosxom-style sites have two weakness. First is the lack of 
storing of meta data, especially permanent timestamps, but also 
information like authorship, draft/publish status, keywords, etc. 
Secondly, in the lack of good web based editing tools. However, 
directly adding meta data and web based editing will cause pyblosxom to 
diverge too much from the original blosxom, and there are complex 
issues that affect performance and make caching more difficult.

I know that we are also facing the fact that the core group of 
pyblosxom programmers do not have the time to invest in significant 
changes to pyblosxom. Yet these are the people who know the current 
system well enough to deal with the complex performance issues that 
meta data will add.


So what can we do?


Here are my thoughts: We should _NOT_ solve these issues in pyblosxom. 
I say that we leave pyblosxom alone, and create a NewProject. (Replace 
with clever name)

NewProject would do the following:

1) Maintain a separate directory structure of all blog entries. These 
blog files will be stored in email format with meta data as headers.  
(I believe this is called RFC 2822 format?).

2) NewProject would be responsible for syncing its directory structure 
with the one used by pyblosxom. At this point the timestamp of the file 
used by pyblosxom would be set according to the meta data.

3) The syncing would convert the  RFC 2822 format to standard blosxom. 
We could also preform other processor intensive rendering. I currently 
do this for rendering of MarkDown formating and my glossary 
substitutions.

4) NewProject would handle blog entry editing and creation via variety 
of mechanisms such as: XML-RPC, webforms, POP3, IMAP, command line, 
etc.

5) Deal with user authentication, draft/publish status, etc.

I have actually implemented parts of each of the above points, but I 
feel that my code is far from acceptable for public consumption and is 
highly incomplete. I hope to work more on this in the middle of 
September.

Other ways of looking at the relationship between Pyblosxom and 
NewProject:

Pyblosxom focuses on Content Serving
NewProject focuses on Content Management.

Pyblosxom is compatible with blosxom-style blog systems.
NewProject _ADDS_ features to _ANY_ plain text file blosxom-style system

Pyblosxom remains a "simple" blog system
NewProject adds features and complexity for people who want it.


-- 
Lee Joramo



-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285