Nuwan, Couple points: a) Will a publisher will be able to create one forum per API (at the time of publishing) .. This should be optional BTW. b) If a developer has not subscribed to an API, will they have access to the forum ?
Can you please share a mockup of the forums viewer ? how is it be embedded in the API store/API publisher page ? Thanks. __________________________________________________ Isabelle Mauny Vice-President, Product Management; WSO2, Inc.; http://wso2.com/ On Apr 22, 2014, at 11:34 AM, Nuwan Dias <[email protected]> wrote: > Hi, > > This is to discuss on the architecture of a Developer Forum on the API Store. > The basic requirement is for an application developer to be able to initiate > discussions on various topics and other developers to be able to reply and > carry on with the discussions. The replies will be on a flat (single level) > structure. The topic creator can also categorize (tag) a topic choosing from > a pre-defined set of categories. > > There will be two ways one can initiate a forum discussion > > 1. Create a generic forum topic by visiting the forums page and clicking on a > button. > 2. Browse to an API detail page and click on a button to start a new forum > topic. In this case the forum topic will be linked to the API and hence one > can filter out discussions for a given API. This requirement brings out the > need for the same visibility rules to be applied on the API as well as to its > corresponding forum discussions. > > The implementation will consist of a back-end and front-end (UI) components. > The back-end will contain the core business logic of the forum's > functionality and will be implemented on top of a defined interface. The plan > is to have the back-end as a separate carbon component. The front-end will be > a jaggery UI. > > The first implementation of the back-end will be a registry based > implementation. Reasoning for opting for a registry based implementation is > as below > > 1. The API permissions model (for visibility) can be reused since APIs are > also registry artifacts. > 2. Pagination support > 3. Registry indexing support > 4. Clear separation of concerns for Multi Tenancy. > > One drawback of the registry is that a given tenant user not being able to > write to another tenant registry. We plan to solve this by allowing that > particular user to comment as 'anonymous' and capture his username via in > input (textbox). > > There will be 3 types of registry resources (rxts) involved in the > implementation. > > 1. topic.rxt - Represents the forum topic. Will have attributes as Subject, > Body, etc. > 2. reply.rxt - Represents a reply for a given topic. Has an association to > topic.rxt > 3. category.rxt - Represents a forum topic category (similar to a tag) > > The resource hierarchy for the topic.rxt and reply.rxt would be as shown below > > > <Forum Registry Architecture (1).png> > > The rxts are stored under a sub-collection of root collection 'topics'. The > sub-collection is a variable which could either be 'common' (for general > topics) and in the form of 'provider_apiname_version' for topics linked to a > particular API(s). The resource permissions are applied to the sub-collection > so that visibility of those topics are handled accordingly. > > Thoughts welcome > > Thanks, > NuwanD. > > -- > Nuwan Dias > > Associate Tech Lead - WSO2, Inc. http://wso2.com > email : [email protected] > Phone : +94 777 775 729 > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
