[Sputnik-list] Forum implementation

[Jim Whitehead II]

I'm in the process of implementing a very simple forums system on top
of Sputnik, but I'm running into a few problems.  A bit about the
structure first:

/forums - Scans node names for anything beginning with forums: and
lists all the open "boards"
/forums:boardname - Scans node names for anything beginning with
/forums:boardname, and lists all open topics
/forums:boardname:topicid - Shows a given forum topic along with any
replies to it

In addition there are buttons that allow you to reply to, and quote a
forum at the topic level.  This all works as expected.  My
concerns/topics of discussion are as follows:

=======================================
1. Categories/Children/Etc. -

I would like to reiterate my request for a way to manage child/parent
relationship to support categorization.  Specifically I was thinking
the following:

local nodes = sputnik:get_node_children("forums")

This would return an array of nodes, where the nodes are the direct
children of the node "forums".  This means it would pull
"forums/general" and "forums/support" but not "forums/general/1".  I
know you've talked/thought about this a bit.. but I'm willing to put
any work necessary to make this sort of change (With guidance).

=======================================
2. Page locking/Name generation

It would be nice if I could expect each page to have a known title,
but when we're talking something like forum threads, it's actually
much easier to provide node numbers on the backend, and give them
titles when they are displayed.  I'm looking for page names like the
following:

/forums/general/8823 - A topic in the forum "general"
/forums/general/8823/1 - A reply to the topic 8823 in forum "general"

There are two problems here:
 * How do I determine the highest node number so I can generate the new name?
 * How do I handle problems with concurrency


I need to be able to generate a node id (ideally when saving) for the
new reply.  I'm really not sure how best to handle this or even if
there is a good solution.  Versium _SHOULD_ be able to handle basic
locking such as through through whatever kind of storage backend is
being used.  Has this been discussed previously?

Another part of this is an easy way to override the save action for a
page.  Right now, these are all sent through the post action, but
there is no way to override the post actions themselves.  Is there a
way the code could be changed so the handler for "post" checks to see
if the action attribute has been set (in this case save) and redirects
the save to the handler instead?
=======================================

That's what I have at the moment, but I'm rather stuck on how to
handle the second item.  I may look at adding versium:lock_node(id)
that pre-allocates a new node and locks it.  This node would remain
locked until explicitly unlocked (which would be the responsibility of
the application layer).

This doesn't eliminate the possibility of a race condition (especially
with regards to a file system), so I'm definitely open to other
thoughts.

Sorry for the random long posts, just trying to work through some of
these issues so I can help with the implementation of any of them into
the sputnik core (where appropriate).

- Jim