Re: filestat - a different perspective

I've been quiet recently because I've been busy and because I've been 
pondering
what to do about pyblosxom.  I initially got involved with pyblosxom 
because
I wanted to learn some Python, I wanted to get some experience with 
various weblog
related technologies, and I wasn't very excited about the various 
weblogging
packages available at the time.

I think that the great strength of pyblosxom is that it's pretty 
hackable.  I think
that we've done a good job on the flow of entries through the pipeline. 
   My blog
is up to 1069 entries and if you try to access it, you're seeing some 
performance
issues that I think are related to multiple walks of the directory 
hierarchy initiated
by multiple plugins that don't communicate with each other.   This is a 
bigger issue
for me than the ability to handle additional meta-data (although I am 
interested in
that problem as well).  I'm probably going to end up moving my blog 
onto WordPress,
although I expect the migration to be a royal pain, so I keep 
procrastinating.

As far as web based CMS types of features, that's something that I'm 
not particularly
interested in working on.  I've used both ecto and NetNewsWire's weblog 
editor to
handle my blog posting for quite some time now, and I prefer the 
ability to work
offline to a web-based solution.

Morgen Sagen at OSAF has implemented servlet style functionality for 
Chandler:
<http://lists.osafoundation.org/pipermail/dev/2004-July/001648.html>.   
I'm probably
going to start working on blogging functionality for Chandler, using 
pyblosxom's
entry pipeline and renderer system as a starting point.  I think this 
will probably
turn up some points where we didn't abstract entities enough (we'll 
see).  I expect
to send relevant patches back to pyblosxom as I do this.

Ted

On Aug 20, 2004, at 10:33 AM, will guaraldi wrote:

>
> I'm not really sure I agree with your assessment--but these are minor
> points, I think and don't cause any ...  uh, i guess reduced 
> justification
> of your proposed solution.
>
> Entries can store meta-data.  In the .txt entries, the meta-data 
> appears
> between the title and body.  That's how my plugin registry works.
> There's an issue with filestat specifically because filestat was 
> designed
> to look at the information the filesystem gives us and we do filestat
> before we've opened the file in question, so we don't have the data
> available.
>
> But maybe I'm not catching what you mean by "meta-data".
>
> In regards to lack of blogging tools, I've got xml-rpc set up with my 
> blog
> using the contributed plugin and it works with w.bloggar just fine.  
> Ted
> or Wari tested out a few other systems and I don't recall us having
> problems with them either.
>
> Can you provide more specifics as to what tools you would like to work
> that don't work and whether you're expecting these tools to work
> "out-of-the-box"?
>
> Splitting pyblosxom into content creation and content serving projects 
> is
> pretty interesting.  Ted (as I recall) was looking at tying pyblosxom 
> into
> Chandler in some fashion--might want to talk to him about what he's
> envisioning there and whether there's some common ground or not.
>
> /will
>
>
> On Fri, 20 Aug 2004, Lee Joramo wrote:
>>
>> 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.
>
>
> -------------------------------------------------------
> 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
> _______________________________________________
> pyblosxom-users mailing list
> pyblosxom-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/pyblosxom-users
>
----
Ted Leung                          Blog: <http://www.sauria.com/blog>
PGP Fingerprint: 1003 7870 251F FA71 A59A  CEE3 BEBA 2B87 F5FC 4B42



-------------------------------------------------------
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