roadmap 1.0

status: this is the official roadmap for rapple 1.0 scheduled for release in November 2005. requests for new features and/or bug reports can be submitted via the project homepage and will be considered by the team for this or for future releases.

focus: delivery of stable code that provides an interesting set of functionality that is likely to have wide appeal.

1. target platforms

rapple is targetted at the following platforms:

1. Linux (2.x kernels)
2. FreeBSD (4-RELEASE and 5-RELEASE branches)

note a: it is anticipated that rapple will also compile and function on other *NIX variants (e.g., Solaris 8+, OpenBSD 3.x etc.) but this claim has not been extensively tested.

note b: a windows port will not form part of the initial release though one may be included at a future date (if you are interested in participating in such a port then please get in touch with me).

2. coding practices and standards

activities not specific to a particular feature but which have an impact across the entire codebase have been the subject of discussion within the team leading to the formulation of our developer guidelines. throughout the team has agreed on the use of development tools to achieve these objectives which are either mandated (as indicated by underscore) or recommended (as indicated by italics) as follows:

1. code review review of existing codebase with a view to standardising existing practices and/or introducing "best" practices (indent).
2. memory management analysis of code for memory leaks and introduction of mechanisms to eliminate or reduce them (Valgrind).
3. documentation adoption of consistent practices for creation and generation of code documentation (Doxygen)
4. unit testing adoption of a unit testing framework and the creation of test suites and a test runner. code unit tests will be created within the rapple module but other test cases (e.g., sample HTML input files) will be made available in a new cvs test module (cunit)
5. code profiling identification of bottlenecks in the code and selected optimistaions ((g)prof)

3. core functionality

core functionality addresses the fundamental workings of the tool or activities that could have wider impact beyond a specific module.

1. modular workflow the present workflow places the emphasis on the web asset (e.g., passing an asset from each process stage to the next) rather than on the processes (e.g., passing all assets to the XSLT transformation stage). the latter has inherent advantages (e.g., increased efficiency of XSLT transformation by only parsing the stylesheet once) and can simplify the overall flow (e.g., generated assets can dovetail more easily into an existing workflow).
2. PHP processing rapple can, up to a point, process PHP files. for this to work properly it is necessary to partition out of PHP files sections that are likely to cause problems during processing (e.g., where attribute values are set using the PHP output directive "<?=") and to include them separately in from files not directly processed by rapple (using the PHP include command). the insertion of the XML prolog (<?xml version="1.0" encoding="iso-8859-1"?>) also causes problems for PHP interpreters. such issues are not unique to rapple and reflect PHP practices that are inconsistent with XML. nonethless it may be possible to issue warnings for some (e.g., the failure to parse correctly) and correctly handle others (e.g., the automatic removal of the prolog for PHP files).
3. entity handling the XML standard predfines a number of entities (e.g., < to represent a literal <) however source files may include their own entities (e.g., euro entity symbol) which can be resolved against a DTD. the handling of entities by rapple (incl. the use of the catalog mechanism by the libxml library) deserves a review and could be improved. necssary resources can be found in the etc directory of the rapple module.
4. specific failures there exist a number of specific cases where rapple fails to take the correct course of action (e.g., premature closed anchor tags resulting in overflowing link) which are documented in test HTML source files and which the parser module attempts to resolve. the remainder of these cases should be closed in the first release. these test cases will be made available within the new cvs test module.
5. regular expressions regular expression functionality based on the pcre library will be added to rapple to support current and future string processing needs.
6. naming convention a consistent naming convention will be introduced for all types within rapple. for example functions will take the form prefix + module + name (e.g., concat in strutil.c will become rpl_strutil_concat etc.)

4. features

features refers to activities that are specific to a particular module and/or have a significant value to the end user.

1. cataloging in some cases a directory in a website is used merely as a file container and there is no obvious linkage from the rest of the website to the material contained therein. cataloging addresses this by parsing the contents of each of the files in the directory and generating a list entry for each file derived from its title and a summary (or digest) of its contents.
2. link checking once built the internal links within a website can be verified and a report (e.g., to stdout or to an XML file) can be generated. in addition to checking "href" attributes of anchor tags the link checker is also reponsible for validated other file related attributes (e.g., "src" of the img and link tags etc.). verification of external links is rarely sensible and is considered out of scope for this activity.
3. rss feeds rss is a news syndication format and this activity concerns the generation of basic rss feeds following a site build. the precise nature and format of the generated feed requires some analysis.
4. MySQL database support rapple is expressly not a content management system (CMS) and it is not within the project scope to add such functionality to the codebase. notwithstanding it is possible to support other tools wishing to add CMS services on top of rapple by exposing necessary information concerning builds via a database table. this activity covers the database design, table creation SQL scripts and the code required to support MySQL. MySQL support should be a compile time option and the necessary library checks should exist in the appropriate autotools files.
5. Berekeley datastore as an alternative to using the filesystem datastore a BDB datastore should be supported. access to the datastore should be done via the datastore module and all client code must be completely unaware of which type of datastore is in effect (filesystem or BDB). choice of such a datastore would ordinarily be justified on grounds (e.g., access control) that the code should be mindful and supportive of. BDB support should be a compile time option and the necessary library checks should exist in the appropriate autotools files.

5. interfaces

interfaces define the interaction of the user with rapple either as a direct user (command line interface) or an indirect user (web front ends that in turn invoke rapple functionality). in the case of the former it is the codebase that is impacted. in the latter a new cvs module, resources, will be created to contain optional and proof of concept materials that rapple users are likely to want to use to be inspired by but which are not essential to a local running instance of rapple.

1. command line interface the primary command line interface (rapple.c) supports a variety of options and functions for processing assets. in addition there is a CGI interface and scope for other forms of interface (e.g., UNIX filter). this activity concerns the unification of the command line interface e.g., perhaps by have a central cli module and a number of specialised clients.
2. PHP contributor interface it would be useful to have in our resources module a PHP file upload script (with support for authenticated HTTP use) that invokes wrapple (formerly rapple_cgi) on behalf of the end user. this might correspond to a contributor role with an orgnaisation. this activity calls for a production quality but transparent implementation that the end user can adapt or feature for their own use.
3. PHP administration interface it would be helpful to have a web based interface from which the user can invoke rapple to build a website. this might correspond to an administrative role within an organisation. the interface might require MySQL support on the underlying rapple and be capable of rendering the status of web assets in tabular format, view link checker reports and access the contents of generated files (e.g., original sources, tidy error reports etc.). the interface must be capable of accessing such resources entirely and exclusively via the datastore module and should be ignorant of its implementation (e.g., as filesystem or BDB). this activity calls for a production quality but transparent implementation that the end user can adapt or feature for their own use.

6. support

support refers to those activities that we as developers undertake to ensure that end-users are sufficiently informed and supported in their use of rapple.

1. website documentation this concerns the accuracy of information on the website in particular the sections concerning building, using and configuring rapple. also important are timely and accurate additions to the faq and other resources that end-users are likely to consult. if you are involved in an activity that impacts the usage of the tool (e.g., command line options etc.) then please ensure that adequate documentation makes its way to the website.
2. sample XSLTs having interesting XSLT (and perhaps CSS) samples is likely to convince new users to adopt rapple. this activity calls for transparent but production quality templates to inspire new users.
3. context highlighting it is possible to introduce a mechanism whereby the context of a page within the site can be reflected using CSS classes alone (one application is the highlighting of menu items based on the page on display). this activitity calls for a pure XSLT solution with minimal impact on the codebase. as part of the activity the basis for an XSLT library (librapple.xsl) should be introduced.