On Tue, Apr 22, 2014 at 4:15 PM, Isabelle Mauny <[email protected]> wrote:
> 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. > Actually this forum is a 'Developer Forum' for App Developers. So its only available on the API Store and hence the API publisher does not play any role in this. b) If a developer has not subscribed to an API, will they have access to > the forum ? > Yes, all forum topics are public unless a topic is associated to an API that has restricted visibility. > > Can you please share a mockup of the forums viewer ? how is it be > embedded in the API store/API publisher page ? > Don't have a mockup right now, will try to come up with one. Let me try to quickly visualize it for now :) You'll have a new Page on the API Store called 'Forum'. When you visit this page you see the list of Forum Topics. Clicking on a topic will allow you to see the discussion (replies). There'll be a button on this page saying 'Create new Discussion' which will create a new general forum topic. There'll also be a search option on this page. On the API detail page of the API Store, you'll have a button saying 'Start new discussion on this API'. When you click on it, you'll be able to create a new forum topic. In this case, the API and the forum topic will be associated and share a common permissions model for the sake of visibility. When on the API detail page, you'll also be given an option to 'View all discussions of this API'. This will list down all forum topics that are associated to the API. Thanks, NuwanD. > > 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 > > -- 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
