«

On Wed, 2006-09-13 at 00:29 -0700, Cliff Wells wrote:

> Anyone aware of any functional (doesn't need to be complete, beta is
> fine) blog software written in Python?

Hmph. And as soon as I hit send I find

http://wiki.python.org/moin/PythonBlogSoftware

Okay, so is there any *not* on that list that should be considered (and
perhaps added to the list)?

Regards,
Cliff

--

Cliff Wells wrote:
> On Wed, 2006-09-13 at 00:29 -0700, Cliff Wells wrote:
>
> > Anyone aware of any functional (doesn't need to be complete, beta is
> > fine) blog software written in Python?
>
> Hmph. And as soon as I hit send I find
>
> http://wiki.python.org/moin/PythonBlogSoftware
>
> Okay, so is there any *not* on that list that should be considered (and
> perhaps added to the list)?

Firedrop2 is a client-side blog program (generates static HTML to be
uploaded to your webserver).

The link on that page is out of date. It is now :

http://www.voidspace.org.uk/python/firedrop2/

You can see a feed of some blogs created with Firedrop2 at :

http://www.voidspace.org.uk/planetfiredrop/

Fuzzyman
http://www.voidspace.org.uk/python/index.shtml


>
> Regards,
> Cliff
>
> --

On Wed, 2006-09-13 at 08:22 -0700, Fuzzyman wrote:
> Cliff Wells wrote:
> > On Wed, 2006-09-13 at 00:29 -0700, Cliff Wells wrote:
> >
> > > Anyone aware of any functional (doesn't need to be complete, beta is
> > > fine) blog software written in Python?
> >
> > Hmph. And as soon as I hit send I find
> >
> > http://wiki.python.org/moin/PythonBlogSoftware
> >
> > Okay, so is there any *not* on that list that should be considered (and
> > perhaps added to the list)?
>
> Firedrop2 is a client-side blog program (generates static HTML to be
> uploaded to your webserver).

I looked at this but didn't care for it as it doesn't appear to allow
for comments (feature-wise it's a few steps down from Frog, which I
already have working).

For anyone who's interested, what I finally settled on was Bitakora. It
violated one of my own requirements (it runs on Zope), but because it's
multiuser and quite featureful and modern, the tradeoff seemed worth it:

http://www.codesyntax.com/bitakora/about

I will say that installing it was something of a pain. If the Zope guys
want to know why Zope has been left behind, one of the first things I'd
suggest is to clean up zope.org. Bitakora has several dependencies and
nearly all of the links to these dependencies led me on a wild goose
chase of broken links, multiple incompatible versions, incompatible
forks, etc.

For those who might follow in my footsteps, the dependencies (with
correct links to correct versions) are:

Epoz: http://iungo.org/products/Epoz/
Localizer: http://www.ikaaro.org/localizer
TextIndexNG2: http://opensource.zopyx.biz/OpenSource/TextIndexNG
CookieCrumbler: http://hathawaymix.org/Software/CookieCrumbler

It also depends on BTreeFolder2, but that's included in the latest Zope
2.8 series.

I think the worst of all of these was surprisingly Epoz. There are at
least three distinct branches of this product: the original
(deprecated), it's replacement (kupu), and a fork (which happens to be
the correct one). The information on zope.org gives little indication
that there might be such a fork (but is quite happy to lead you in
circles). I noticed that several of the products mentioned the pain of
maintaining software on zope.org (and so had moved their software
elsewhere), so this is probably the root of the problem.

Anyway, Zope complaints aside, Bitakora is really great and I'd
recommend that anyone looking for a friendly, multiuser blog take a
look.


Regards,
Cliff

Cliff Wells wrote:
> On Wed, 2006-09-13 at 08:22 -0700, Fuzzyman wrote:
> > Cliff Wells wrote:
> > > On Wed, 2006-09-13 at 00:29 -0700, Cliff Wells wrote:
> > >
> > > > Anyone aware of any functional (doesn't need to be complete, beta is
> > > > fine) blog software written in Python?
> > >
> > > Hmph. And as soon as I hit send I find
> > >
> > > http://wiki.python.org/moin/PythonBlogSoftware
> > >
> > > Okay, so is there any *not* on that list that should be considered (and
> > > perhaps added to the list)?
> >
> > Firedrop2 is a client-side blog program (generates static HTML to be
> > uploaded to your webserver).
>
> I looked at this but didn't care for it as it doesn't appear to allow
> for comments (feature-wise it's a few steps down from Frog, which I
> already have working).
>

Because it is client side (rather than running on the server), it has
no built in comments facility. I use Haloscan for comments, but I'm
always on the look out for a neat comments system to integrate with
Firedrop.

I personally prefer the 'client side' approach, as it makes migrating
content to another server trivially easy.

All the best,


Fuzzyman
http://www.voidspace.org.uk/python/index.shtml

Fuzzyman wrote:
>
> Because it is client side (rather than running on the server), it has
> no built in comments facility. I use Haloscan for comments, but I'm
> always on the look out for a neat comments system to integrate with
> Firedrop.
>
> I personally prefer the 'client side' approach, as it makes migrating
> content to another server trivially easy.

a wise person you are. I've often thought that most of the pages
generated by web frameworks (except for active pages) should be cached
once rendered.

as to the comment system, I've been very disappointed by most blog
comment capabilities because they actively hinder the ability for
commenters to interact with each other. what I would like to see is a
short-life (i.e. three day) mailing list where the message history is
stored as if it were blog comments.

The advantage of this technique is you can follow the comments without
constantly checking in on the blog And you can actually build a
community which interacts more easily than they do today.

Yes, you could build a web form techniques but the main advantage of Web
forms over mailing lists is that they fill your mailbox with messages
telling you that you have a message instead of delivering the message
itself.

it would be interesting to see if one could build this capability
into/out of mailman. I really hate reinventing the wheel unless the
wheel is square and I need a round one.

---eric

"Eric S. Johansson" <> writes:
> a wise person you are. I've often thought that most of the pages
> generated by web frameworks (except for active pages) should be cached
> once rendered.

Fancy frameworks do use caching, but I think of that as a kludgy
workaround for lousy performance of the framework itself. A fast
framework should not need caching, except maybe caching gzip output
for large blocks of contiguous text.

> as to the comment system, I've been very disappointed by most blog
> comment capabilities because they actively hinder the ability for
> commenters to interact with each other. what I would like to see is a
> short-life (i.e. three day) mailing list where the message history is
> stored as if it were blog comments.

Some comment systems are better than others, but transferring the
comments to email sounds horrible, at least for users who use web
boards to keep stuff OUT of their mailboxes.

> Yes, you could build a web form techniques but the main advantage of
> Web forms over mailing lists is that they fill your mailbox with
> messages telling you that you have a message instead of delivering the
> message itself.

Yeah, that combines the worst of both worlds.

Paul Rubin wrote:
> "Eric S. Johansson" <> writes:
>
>>a wise person you are. I've often thought that most of the pages
>>generated by web frameworks (except for active pages) should be cached
>>once rendered.
>
>
> Fancy frameworks do use caching, but I think of that as a kludgy
> workaround for lousy performance of the framework itself. A fast
> framework should not need caching, except maybe caching gzip output
> for large blocks of contiguous text.
>
The value of caching is mostly for heavy-duty applications built on top
of the framework. The framework has no control over how much computation
the application does, but can offer savings by "short-circuiting" the
repeated execution of lengthy page computations in application code.

regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://holdenweb.blogspot.com
Recent Ramblings http://del.icio.us/steve.holden

Steve Holden <> writes:
> > Fancy frameworks do use caching, but I think of that as a kludgy
> > workaround for lousy performance of the framework itself. A fast
> > framework should not need caching, except maybe caching gzip output
> > for large blocks of contiguous text.
> The value of caching is mostly for heavy-duty applications built on
> top of the framework. The framework has no control over how much
> computation the application does, but can offer savings by
> "short-circuiting" the repeated execution of lengthy page computations
> in application code.

Fair enough. I shouldn't have said "lousy performance of the
framework itself" when I should have included the application. If the
application's page computations are so lengthy, then they too need
speeding up.

We've got a situation where some big sites (Slashdot, Wikipedia) have
a lot of cached static pages for non-logged-in users (they all see the
same thing), but any user who is logged in sees a version customized
by their preferences, that's usually not cached. So there's a
perverse incentive to not log in, since you see the static page
faster.

I'd really like to get hold of a big active blog or BBS server to
profile it. It's been puzzling me for years what makes them so slow.
They just paste user-contributed content together with HTML from
templates, so you'd think it shouldn't be too complicated.

> Fair enough. I shouldn't have said "lousy performance of the
> framework itself" when I should have included the application. If the
> application's page computations are so lengthy, then they too need
> speeding up.
>
> We've got a situation where some big sites (Slashdot, Wikipedia) have
> a lot of cached static pages for non-logged-in users (they all see the
> same thing), but any user who is logged in sees a version customized
> by their preferences, that's usually not cached. So there's a
> perverse incentive to not log in, since you see the static page
> faster.
>
> I'd really like to get hold of a big active blog or BBS server to
> profile it. It's been puzzling me for years what makes them so slow.
> They just paste user-contributed content together with HTML from
> templates, so you'd think it shouldn't be too complicated.


Most of the time, that means fetching data from the DB, which means
context switches and network transfer. I'm a developer on a large
java-driven application that deals with books. The app benefits hugely
from caching - the whole object model is rather elaborated, and fetching
it into memory (including images stored as blobs), and serializing it
takes a couple of seconds. Per user! But just grabbing it from a disk as
html snippet speeds up the app tremendously.

Additionally, commercial sites often are composed by a rather large
number of different parts. Teasers, lists of e.g. thematically related
content and so on. And if you have lots of comparably large objects that
are very diverse, a larger number of users may mean to exhaust memory
quickly or even worse swap it around. All this is remedied by caching.

Diez