[Open-collaboration-services] Open Collaboration Services version 1.6 draft 1 - Forum component problem

Ben Cooksley bcooksley at kde.org
Mon Aug 2 05:39:52 CEST 2010


On Sat, Jul 31, 2010 at 1:22 AM, Ben Cooksley <bcooksley at kde.org> wrote:
> On Fri, Jul 30, 2010 at 11:00 PM, Frank Karlitschek <karlitschek at kde.org> wrote:
>>
>>
>> On 30.07.2010, at 05:51, Ben Cooksley wrote:
>>
>>> == Forwarding to the new mailing list.
>>> == Frank: Please look at the content below, I have recieved no reply
>>> from you, despite sending this directly to you 11 days ago....
>>>
>>
>> Hi Ben,
>
> Hi Frank,

Ping?

Regards,
Ben

>
>>
>> It seams that I missed you previous mail.
>> Sorry for that.
>
> No problem, thanks for replying.
>
>>
>>
>> We are still in the discussion stage. So your feedback is very welcome. I´m sure we can find a way to integrate the forums because this is one of the targets of OCS. :-)
>
> Excellent.
>
>>
>>
>>
>>> Hi all,
>>>
>>> It appears that my previous suggestion for version 1.6, the addition
>>> of a "categories" call to the KnowledgeBase component has not been
>>> performed, and the creation of a seperate "Forum" module has been done
>>> instead. It appears that this module is mostly able to meet the
>>> requirements of providing information about a tree of forums
>>> fortunately.
>>>
>>
>> The idea behind the knowledgebase module is to provide access to question and answers pairs.
>> For example for websites like. answers.yahoo.com, mahalo.com, Linux42.org or stackoverflow.com
>>
>> The new forum module should be used for forums
>
> Agreed.
>
>>
>>
>>> Unfortunately, it appears that absolutely no method exists in the
>>> specification as it is currently published on freedesktop.org to allow
>>> the listing of topics for specific forum(s) only. Nor does any
>>> recommendation exist in the documentation for which modules should be
>>> used to create an implementation for a forum in the Forum module
>>> documentation, if the KnowledgeBase module is not supposed to be used.
>>
>> As I said we are still at the discussion stage of 1.6. So your feedback is very welcome.
>>
>>
>>> I suggest one of the two following solutions to this issue:
>>>
>>> 1) Add a type argument to knowledgebase/list and knowledgebase/add to
>>> allow for choosing between either the "content" or "forum" components.
>>> This would also modify the get call to knowledgebase/get call to
>>> become /v1/knowledgebase/data/<typeid>/<contentid>/
>>
>> As I said. The knowledgebase module should be only provide accesss to a flat list of question and answer pairs.
>> I think the place for a tree view on the forum is the new forum module.
>>
>> You can of course implement both modules in a forum if you want to provide both views on your data.
>>
>>
>>
>>> 2) Add appropriate calls to the Forums component to replicate
>>> knowledgebase/list, knowledgebase/add and knowledgebase/get for the
>>> purpose of a forum.
>>
>> Yes. I´m not an expert on the internals of forums. Perhaps you could provide an proposal for the forum module so that all your requirements could be met.
>> At the moment the idea is that the forum module provides an tree of forums and subforums and threads. You can tan use the existing comments module to attaches discussion trees to this forums/threads.
>>
>> What do y ou think?
>> Can you send an proposal how you want to change this?
>
> I certainly can.
>
> A forum, such as forum.kde.org has essentially three types of information:
>
> 1) Forum
> 2) Topic
> 3) Post
>
> Posts are made to a topic and are mapped to the Comments module with
> little problem. No change needs to be made there.
>
> Topics are posted in a forum, which currently is not too easy to map,
> as it isn't possible to include information on which forum the topic
> belongs to. This is the primary reasoning behind copying the two
> knowledgebase calls, then changing the copies slightly.
>
> In terms of being cleaner as an API in general, simply using only the
> Forum and Comment components is clearer to a developer, especially
> given that Comments already has a Forum type.
>
> This provides the additional benefit of allowing forums and a seperate
> knowledgebase to co-exist on a single site without problems ( I think
> opendesktop.org does this ).
>
> I propose that the following is done:
> 1) Copy knowledgebase/list to forums/topics/list
>    - This would work effectively identical to the knowledgebase/list call
>    - Except the parameter "content" is replaced with "forum" which
> accepts a forum id instead
>
> 2) Copy knowledgebase/add to forums/topics/add
>    - "content" would be replaced with "forum" as with knowledgebase/list
>    - all other parameters to knowledgebase/add are identical
>
> 3) Rename forums/get to forums/list
>    - Simplification mostly, for clarification.
>    - This provides the forum id that will be used as the "forum"
> parameter for listing and adding topics.
>
> In later API versions, the forums module may be extended to provide
> various other operations, such as the ability to vote on brainstorm
> items, or vote in a topic poll. These will likely be added using the
> following pattern: forums/topics/<operation>.
>
> The Forums module will continue to use the Comments module.
>
> The actual forums/topics/list call will only provide a brief overview
> on a topic, and will not provide the first post of a topic.
> The Comments module calls will be used to provide this, as it
> simplifies client implementations ( because otherwise clients have to
> make two calls to display an entire topic )
>
> Any comments on this?
>
>>
>>> Either of the above two options is fine by me. I would like to modify
>>> the OCS API as currently provided by the Forum to be compliant with
>>> the altered specification as soon as possible, but cannot do that
>>> until the ability to retrieve the list of topics from a forum id is
>>> possible.
>>
>> Sure. I´m very happy that we work together here. :-)
>
> Regards,
> Ben
>
>>
>>
>>>
>>> Regards,
>>> Ben
>>
>> Cheers
>> Frank
>>
>>
>> --
>> Frank Karlitschek
>> karlitschek at kde.org
>>
>


More information about the Open-collaboration-services mailing list