Restructuring opensolaris.org

 The current opensolaris.org infrastructure has issues in several areas:

• Functionality
• Flexibility
• Modularity
• Extensibility
• Stability & maintainability

 This page attempts to explain these issues in more detail, along with proposed solutions. If you have any questions or comments about the contents of this page, please send them to the auth-discusss-ext mailing list at sun.com. See also http://auth.opensolaris.org/ for the current in-development version of the new user management webapp for opensolaris.org

Vision

 At present the web application which provides opensolaris.org is a custom-written monolithic J2EE application that provides all the functionality for the website. As the OpenSolaris community evolves the requirements for opensolaris.org will also evolve, and the current webapp is a poor fit for both the present and future needs of the community.

 The intention is to move towards a collection of interconnected, lightweight web applications so that functionality may be added, retired or replaced without requiring wholesale changes to the entire opensolaris.org infrastructure. Work towards this aim is already in process, for example the OpenGrok, SCM console, Code Review and Self Test components of opensolaris.org are provided as separate but cooperating webapps. This page discusses the steps necessary to migrate away from the existing webapp to a new framework.

OpenSolaris user cookies

 opensolaris.org uses a HTTP cookie to hold the details of each logged in user. The user cookie has evolved through several versions, yet is still not entirely satisfactory. This document outlines the various cookie formats, along with a proposal for a new format. This document should be read in conjunction with the distributed authentication document.

Distributed authentication

 The current authentication mechanism used by opensolaris.org depends on access to a shared cookie, a shared Java library to manipulate the cookie and a shared Blowfish passphrase to encrypt and decrypt the cookie payload. This is difficult to administer inside the current website 'cage' and once we allow external sites to host components of the OpenSolaris infrastructure it becomes completely unworkable. This document outlines a proposed distributed authentication framework that allows webapps to use the services of a central authorisation service in a secure and controlled manner.

Centralised cross-domain login (SSO)

 As we move towards a federated system of cooperating webapps, we need to provide a centralised mechanism that all the webapps can use to allow users to log in. Requiring that each webapp reimplement a login mechanism is both wasteful and prone to security issues. This document describes a secure, centralised cross-domain login mechanism (SSO) that can be used to provide login management for webapps providing parts of the OpenSolaris infrastructure.

Consistent opensolaris.org 'look and feel'

 Although we are moving towards a model where opensolaris.org functionality is provided by a set of loosely-connected web applications, we still want to preserve a common look and feel across all the components. At present all the common graphical elements associated with the site (menus, icons, stylesheets etc.) have to be manually replicated across each component webapp. The proposal is to build a central service that will provide a centralised location for all opensolaris.org L&F components.

Content authoring

 At present the content on opensolaris.org is entered using either raw HTML or with a opensolaris-only markup language called TML. It is proposed that this be replaced with a WYSIWYG editor such as TinyMCE, configured to accept only XHTML. This would make it easier to enforce consistent styling across the site. A further suggestion is to replace the current custom content management with a wiki-based system, based on a customised version of an existing wiki package such as XWiki.

 An important constraint is that any chosen solution must have good localization facilities. These are needed both to support translation of the site content, and to allow user groups in particular geographies to provide their own language-specific areas of the site. For more details of the requirements and the work that has been done to date, see the OpenSolaris portals project.

Site search

 At present the site search facility for opensolaris.org is embedded inside the webapp which provides the site content. When a page is edited, it is immediately reindexed by the webapp, which uses Lucene to implement the search functionality. This has an unfortunate side effect of massively inflating the footprint of the webapp - the current opensolaris.org webapp requires over 2Gb of RSS to run. This centralised mechanism is also obviously not suitable for an architecture consisting of distributed webapps.

 The suggested architecture for the new search mechanism is to provide a central webapp that can provide search management facilities for all the components of opensolaris.org. This would use the Solr open source search server, which is based on Lucene. Solr provides an XMLRPC interface that allows federated search management - partitipating applications can add, modify and delete content from the central search server using the XMLRPC interface. In addition it also provides facilities for load balancing and index distribution.

Forums

 The forum software currently used on opensolaris.org is Jive. Unfortunately this is not open source, so it cannot be made freely available to the OpenSolaris community. It is also a source of frequent complaints about the site, and therefore needs replacing. Various suggestions have been made, including disposing of the forum facility altogether and just using email lists, providing a NNTP service or using a different, open source forum package. No decisions have been made, and this area needs further thought and investigation.

Mailing lists

 The existing mailing lists and archives use the MailMan list manager, which seems to be the only really viable open source implementation. This has been broadly satisfactory, and there are no immediate plans to consider an alternative. The one area that has been troublesome is the integration between the Jive forum software and MailMan. Any replacement for Jive should have good integration with MailMan.