« Back

Rss aggregator spec, following LJC template

Spec: RSS in for content aggregation#

1. Overview

1. Intended Audience

Prospective coders, mentors, and managers of this project. Project manager is Richard Hering richard@visionon.tv 07894350478

2. Project Scope and Product Context

RSS in and out by multi-tagging

Scope: To create a tool which will query a site for an RSS feed based on a tag rather than the whole site. Can create an RSS feed from a tag query rather than the whole site Thus can by boolean logic automate feeds in and out of each site's articles to query a site for an RSS feed based on a tag rather than the whole site. This is key as it empowers the producer rather than the techie at the centre to influence where the content ends up. Tech notes Can do real-time scaling with Pub Sub Hubbub, fat pings and RSS feed timed caching (queries are only updated once every set time period) Of course, this falls back to simple site RSS for the whole web of non “compliant” sites, means some one has to put more effort to sorting them.

3. References and Further Reading

<Links to existing documentation, whether internal, product-related or Internet>

2. Detailed Environmentals and Constraints

1. Users

Initially, the core visionOntv crew – non-geeks. Exemplar for other people to implement the same functionality in their own cms. Released back into the liferay community as an open source solution.

2. Operating Environment

<What environment will the new features operate in? The stand-alone runs on a web server environment, the plug-in runs on liferay. (Eg OS, Software suite, hardware if relevant. Is it a hosted service, cloud, something else?) Hosted on a web server – could be in a cloud if on Amazon (its open source implementations) – needs to run independently, not tied into corporate structures

3. Pre-existing Design/Implementation Constraints

<What limits are placed on the developers by the existing systems? Must work with liferay standards. Specific choices of languages? Preferably java, as liferay is java-based, but open to any suggestions. Specific tools or technologies? Xml, rss.

4. Assumptions and Dependencies <Any other assumptions / dependencies not covered by the above> code has to be understood by other people – not spaghetti code – as we want to open source the code, it must be readable and developable by other coders.

3. Detailed Requirements

<In this section, we will address each detailed req in turn. Each requirement should fill out 1 – 4 below>

1. Requirement Reference

<Each requirement should be uniquely identified with a sequence number or a meaningful tag of some kind. E.g. REQ-1>

2. Description and Priority

<Provide a short description of the feature and indicate whether it is of High, Medium, or Low priority. You could also include specific priority component ratings, such as benefit, penalty, cost, and risk (each rated on a relative scale from a low of 1 to a high of 9).>

3. Stimulus/Response Sequences

<List the sequences of user actions and system responses that stimulate the behavior defined for this feature. These will correspond to the dialog elements associated with use cases for GUI features.>

4. Functional Requirements

<Itemize the detailed functional requirements associated with this feature. These are the software capabilities that must be present in order for the user to carry out the services provided by the feature, or to execute the use case. Include how the product should respond to anticipated error conditions or invalid inputs. Requirements should be concise, complete, unambiguous, verifiable, and necessary. Use “TBD” as a placeholder to indicate when necessary information is not yet available.>

4. Non-Functional Requirements

<In this section, we will address each detailed NFR in turn. These should typically cover Performance, Security & Quality as a bare minimum. Each requirement should fill out a)-b) below>

1. Requirement Reference

<Each requirement should be uniquely identified with a sequence number or a meaningful tag of some kind. E.g. NFR-1>

2. Description and Priority

<Provide a short description of the NFR and indicate whether it is of High, Medium, or Low priority. You could also include specific priority component ratings, such as benefit, penalty, cost, and risk (each rated on a relative scale from a low of 1 to a high of 9).>

0 Attachments
1898 Views
Average (1 Vote)
The average rating is 2.0 stars out of 5.
Comments