[Sputnik-list] Forum implementation

[Jim Whitehead II]

>  Sorry I have posted previous response to mailing list.
>  I haven't see that you mailed just to me.

Apoligies, I didn't mean to send to only you, meant to send to the
entire list.  No problems.

"Sputnik is a wiki written in Lua. It is also a platform for building
a range of wiki-like applications, drawing on Lua's strengths as an
extension language."

Look at wikipedia or any other wiki.  The talk pages are the perfect
example of the social collaboration I'm aiming for, combined with the
solid collaborative documentation of a wiki.

Admittedly, mine is a very custom application that has very specific
needs and I'm doing what I can to implement them on top of the sputnik
layer without having to add a bunch of hacky primitives to the core.
It seems this is what Sputnik was designed to do.

I'll have a re-think about some of these solutions, but a core
"problem" I see is the issue of concurrent editing.  Taking things
outside the wiki, outside of my forums, outside of everything else,
these are the problem Im' trying to find solutions to.  They are
_core_ sputnik issues and have nothing to do with however I'm trying
to twist the system.

When two users edit the same node, versium/saci needs to be able to
handle their saves being interleaved.  Right now the simple storage
mechanism cannot handle this without the posix O_CREAT and O_EXCL
flags, so there is a race condition on both the new node.  You can't
do any error checking without the posix flags, so you have a race
condition on the revision creation.

When using a mysql backend, I can detect this because of the way the
system is designed.  When commiting a new node revision, I can
determine if the commit fails due to a primary key violation and give
an error message back to the user (or raising it to some level in the
sputnik/versim system).

The index file is another issue.  With using a central indexing file
instead of timestamps, you have a really bad race condition on the
editing of that file.  Using timestamps is certainly one solution, but
that relies on the system timestamp never changing (consider daylight
savings time and other related issues).  This, I don't have a solution
for.

I'm going to start up some wiki pages that details the user experience
as intended and then hopefully once we have something decided there we
can move onto the api and specific implementation that is required to
meet that experience.  I don't anticipate much is going to change
overall, but I think it's a good place to start.

- Jim