I'm currently developing a blog in Enki and it occurred to me that it
would be useful if there were some guidelines as to what is envisaged
as being included in Enki and what will always be left to the
developer to do himself.

For example - caching. At the moment (as far as I can see) there is no
provision for caching in Enki which means the developer will have to
roll his own. Not a problem, but will caching always be left down to
the developer or are there plans to have this eventually incorporated
into the default codebase?

Now I completely understand the premise of keeping things simple (and
it makes Enki a joy to work with because people can actually
understand it without studying it for hours on end!), but it would be
really helpful if we had some clear guidelines as to just how simple
Enki will remain and what we should always expect to have to do for
ourselves. No one wants to roll their own feature only to discover it
was on the Enki roadmap all along and their effort was wasted.

Another example of needing some guidelines is I've implemented an
archive history feature on my blog which lists the months and how many
posts were on that month in the navigation sidebar. Clicking on a
month then shows you all the posts for that month.

Nothing amazingly complicated but handy to have and pretty common on
other blogs. But is this something which you'd be interested in having
in Enki as standard or is this firmly in the "if you want it, do it
yourself" area? If you'd be interested in pulling it into Enki I'd put
it on Gihub, but if this kind of thing is always going to be in the
end user domain then it's probably not worth my while making it
public.

You see what I'm getting at with this? Just a few rough guidelines as
to what Enki will never do, what is planned and what you're interested
in having in Enki should people have their own solutions that they
could share.

Cheers

however in the main repository I want to keep update significant forks
that could be handy to people. Currently there is a multiple-authors
branch, next on the list is to get a branch that does spam filtering
(there are a few of these in the wild - rhnh.net and smartbomb.com.au
both have their source available). A caching fork would also belong here
(does not exist AFAIK). Sphinx integration would also go here (another
thing that is on rhnh.net - you get 'related articles')

 > Nothing amazingly complicated but handy to have and pretty common on
 > other blogs. But is this something which you'd be interested in having
 > in Enki as standard or is this firmly in the "if you want it, do it
 > yourself" area? If you'd be interested in pulling it into Enki I'd put
 > it on Gihub, but if this kind of thing is always going to be in the
 > end user domain then it's probably not worth my while making it
 > public.
The ideal is to get as much public enki code as possible. Everyone has a
different idea of how archives should be presented. Theoretically it
should then be easy to cherry-pick the features that you want.

I realise in practice it's not quite that simple (yet).

An immediate improvement would be a central index of where things are.
Better guidelines for how to develop in a manner that makes it easy for
others to use your code would also help, I think (basically you want a
fork of trunk per "feature", then a fork for your website).

Is that kind of what you were looking for?
Xavier

That's a pretty neat way of doing it because I assume you could then
merge together branches that have all the features you want whilst,
importantly, still keeping the master branch clean and simple. Very
nice!

That also removes the problem of deciding what goes in Enki and what
doesn't because the end user can decide. I can see why you've chosen
that route now and I'm kicking myself for not thinking of it earlier.

Perhaps it might be an idea to explain this in the README.textile? I
can only assume others may benefit from having this explained as well.

Once I've finished my blog I'll pop the code up on github for the way
I'm handling archiving so you can take a look. It's nothing
spectacular by any means, but it may help. Could be a while as I'm
quite a way from finishing.

Any idea of roughly how long the spam filtering will be? I can see
that being a pretty core feature to have.

Cheers