[Sputnik-list] Forum implementation

[pierre pracht]

Le 6 mars 08 à 12:30, Jim Whitehead II a écrit :

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

No, it's me, so many time I forgot to use reply all.
I have think that it has been the case.

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

Yes, that's why sputnik interest me too.
It's just that IMHO locking isn't the way to go.
For implementation take a look at :
http://www.couchdbwiki.com/index.php?title=Basic_Application_Schema_Example
At user level :
If we can take in account concurrent edit of wiki page, why use a  
different way for discussion ?

> 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 think that sputnik can make many things but it lack an index function.
function SimpleVersiumStorage.get_matching_ids(self, partial_id)

And it can be generalized. A simple implementation of couchdb view can  
be donne in lua.
Take a look at couchdb. In sputnik it can be implemented the same way  
than my previous example : simple_compose.

What we need is a way to initialize and access several storage (or  
index/view) from page / action.
Actually repository initialization and access belong exclusively to  
sputnik core.
May be split page processing (keep in sputnik) and node querying (new  
class)

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

What have proposed Yuri :
>> If the client tries to save edits to revision N but the latest
>> revision of the node in N+m, then we need to have a way of letting
>> them know
Would work.

My point of view, is that we can find similar way for many problem.

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

My solution for file storage wouldn't give you locking, but would work  
with low requirement.
>> Concurrent modification of a file would be a nightmare in simple  
>> storage (and other). Better to avoid it at all. Why no rely on file  
>> creation time to order version. Never modify file and differentiate  
>> them by a generated uuid.

And if you store time-stamp (and key) in document, it would work with  
any storage.

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

So what is the difference with :
   Save it anyway.
   And after check if it is the last one.
   If not warm the user.
With your solution you need to save current user edit in session to  
not lost it.

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

No split the problem :
  - use uuid : http://en.wikipedia.org/wiki/Uuid
         for storing document
  - store utc time-stamp in document (for sorting)
  - store key in document
  - keep an index on key / utc time-stamp

index would be an other type of storage in sputnik

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

Good idea

- pierre