Rifidi roadmap
From RifidiWiki
This page discusses some long range plans for the Rifidi project.
Contents
Current State
Currently, the Rifidi products (Designer, Tag Streamer, and Emulator) are three totally separate software packages with little code reuse (except for readers) and loose coupling integration. Functionality is separated into osgi plugins, but code is not being developed with the service-oriented paradigm that osgi provides. this causes several problems:
- Three Separte Development Cycles for Rifidi Designer, Tag Streamer, and Emulator
- Version Numbers apply only to releases, not to underlying services provided by osgi plugins
- too much code is copied and not shared
- There is alot of functionality that is not separated into plugins
- Stable code mixed with development code
- If only one small part of a class changes, the whole plugin has to be updated
- Rifidi is missing an eclipse-like 'update' functionality
As a result, we end up with three separate, but related projects that are loosely-coupled
Solution through Service Oriented Architecture
In order to tie the three products closer together, we should use the services-oriented design that osgi allows for. We can achieve this by following the following best practices:
- Functionality needs to be separated into services (i.e. plugins).
- osgi plugins should be versioned separately from releases. We can do this in the manifest file of the plugin
- Each bundle should have a maintainer. This can also be specified in the plugin's manifest.
- The most important idea is that Rifidi should be treated as one application with several possible ways of assembling functionality.
Rifidi As Single Application
If Rifidi is a single application, it gives several benefits:
- Single Installer - There can be a single, small Rifidi Installer that allows users to install the Rifidi functionality that they want. For example, once they have the base application running, they can choose to install the 'designer' packages or the 'tag streamer' packages.
- Update Functionality - When a user wants the latest version of the code, he can update the application, which will install only the latest osgi plugins instead of having to download the whole rifidi application again.
- Reliability - By focusing on the functionality at the package level, we can note when a package changes and update the version number of the package itself. In addition, plugin dependencies can specify version number that they depend on. This allows us to know which package versions work with the current code in case something breaks. Because each plugin can be tagged in the SVN, a 'release' is simply a collection of plugin version numbers.
- User Upgrade Path - By having an installer with the ability to add new functionality, it provides a user with a clear upgrade path in using the Rifidi Products, for example:
Steps to Complete
- Separate functionality into plugins and identify common code that is currently being duplicated.
- Design new packages for the duplicated code. The new packages should be able to be used by all products.
- Develop a 'best practices' guide for how to number osgi packages. Go through all packages and give them version numbers
- Create a new svn repository and add all new packages to it
- Add update functionality within the products
- Host site for serving package updates
- Develop common UI framework