[Sputnik-list] Forum implementation

[pierre pracht]

Le 6 mars 08 à 09:01, Jim Whitehead II a écrit :

> On 3/6/08, Yuri Takhteyev <yuri at sims.berkeley.edu> wrote:
>>
>>> /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
>>
>> Let's just allow "/" in node names.  It's a two-line fix to versium
>> (see below).  To start off, "forums/boardname" would be a separate
>> node, not related to "forums" (except that you can select it by
>> prefix).

Why not put a requirement on storage :
URL are allowed as key so storage must escape all needed char ?

>> We'll later add functionality (in the higher-level
>> super-versium/saci, formerly known as "versium.smart") to ask "forum"
>> to tell us where to look for it's child "boardname."  If "forums"
>> doesn't tell us this (or doesn't exist) then we'll just default to
>> asking versium for a module called "forums/boardname".  This would
>> make it backwards compatible.

An why not just let "forum" and "forums/boardname" exist as key in  
storage.
Extra field or key sorting would handle hierarchy.

>>> 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")
>>
>>
>> Agreed.  This would be a feature in "saci.node" (today's
>> "versium.smart.smartnode").  Here is how it could work:  We would
>> check node.children, and if this field is _not_ defined, we'll just
>> ask versium for a list of nodes that start with "forums/" and do not
>> have the second slash.  However, alternatively, node.children can
>> contain an new versium configuration.  In which case we'll ask _that_
>> versium instance of _all_ of its nodes and return them with a
>> "forums/" prefix.  I am thinking that it should return the list of
>> node IDs rather than loaded nodes.

function SimpleVersiumStorage.get_matching_id(self, partial_id)
    local ids = {}
    for id, _ in pairs(self.node_table) do
       ids[#ids+1] = id
    end
    table.sort(ids)
    local matchs = {}
    for _,v in ipairs(ids) do
       if (string.find(v,id)==1) then
          table.push(matchs,v)
       end
    end
    return matchs
end

Key indexing is most efficient in storage.
But I agree that it must be separate from storage requirement. As not  
all storage can handle it. An other layer can provide indexing and  
pass it down when storage support it.

> Again, I'm wary of storing that relationship in the node itself,
> simply because of the issues with concurrent edits.  If we can get
> that resolved, then I agree.

See later.

>>> 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"
>>
>> In the short term, you can use a hash of the title/content instead of
>> a sequential number.  But I agree that in the long term it would be
>> good to be able to do what you are suggesting.

Or simply generate key from post title :
forum presentation : "My first post" ->
/forums/presentation/my_first_post
And warm user if topic title have been previously used.
(a side effect, it would be seo friendly)

When a user start a topic, it didn't create the topic. It just make  
the first post with a never used title.
/forums/presentation/my_first_post/--146node_id56--
If it didn't exist system can create a topic node for commodity, but  
concurrent creation wouldn't be harmful as it would just create two  
version.

If topic node need to be edited (e.g. lock topic :) ), storage would  
just make a new version who would take over previous.
For right management : a user can (implicitly) create a topic node if  
It didn't exist previously.
A moderator can edit (create new version).

A general think :
  - Avoid locking
  - Just guaranty writing of data
  - Application must check version
Or you can use a database.

- pierre