Difference between revisions of "Rifidi roadmap"
From RifidiWiki
| (8 intermediate revisions by 6 users not shown) | |||
| Line 3: | Line 3: | ||
=Current State= | =Current State= | ||
| − | + | Currently, the Rifidi products (Tag Streamer, and Emulator) are two 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: | |
| − | + | ||
| − | + | ||
| − | Currently, the Rifidi products (Tag Streamer, and Emulator) are two | + | |
*Two Separte Development Cycles for Rifidi Tag Streamer, and Emulator | *Two Separte Development Cycles for Rifidi Tag Streamer, and Emulator | ||
** Version Numbers apply only to releases, not to underlying services provided by osgi plugins | ** Version Numbers apply only to releases, not to underlying services provided by osgi plugins | ||
** too much code is copied and not shared | ** too much code is copied and not shared | ||
| − | *There is alot of functionality | + | *There is alot of functionality that is not separated into plugins |
**Stable code mixed with development code | **Stable code mixed with development code | ||
| − | |||
**If only one small part of a class changes, the whole plugin has to be updated | **If only one small part of a class changes, the whole plugin has to be updated | ||
*Rifidi is missing an eclipse-like 'update' functionality | *Rifidi is missing an eclipse-like 'update' functionality | ||
| − | + | As a result, we end up with two separate, but related projects that are loosely-coupled | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | As a result, we end up with two separate, but related | + | |
=Solution through Service Oriented Architecture= | =Solution through Service Oriented Architecture= | ||
| − | In order to tie the services-oriented design that osgi allows for. We can achieve this by following the following best practices: | + | In order to tie the two 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 | + | * Functionality needs to be separated into services (i.e. plugins). |
| − | * osgi plugins should be versioned separately from releases | + | * 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 | + | * 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. | * The most important idea is that Rifidi should be treated as '''one''' application with several possible ways of assembling functionality. | ||
=Rifidi As Single Application= | =Rifidi As Single Application= | ||
If Rifidi is a single application, it gives several benefits: | If Rifidi is a single application, it gives several benefits: | ||
| − | *'''Single Installer''' - There can be a single, small Rifidi Installer that allows | + | *'''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 'emulator' 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 | + | *'''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 | + | *'''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: | |
| − | + | ||
| − | + | ||
| − | which package versions work with the current code | + | |
| − | + | ||
| − | + | ||
| − | *'''User Upgrade Path''' - By having an installer with the ability to add new | + | |
[[Image:RifidiRoadmap.png]] | [[Image:RifidiRoadmap.png]] | ||
| Line 51: | Line 35: | ||
=Steps to Complete= | =Steps to Complete= | ||
# Separate functionality into plugins and identify common code that is currently being duplicated. | # 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. | |
| − | # Design new packages for the duplicated code. The new packages | + | |
# Develop a 'best practices' guide for how to number osgi packages. Go through all packages and give them version numbers | # 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 | + | # Create a new svn repository and add all new packages to it |
# Add update functionality within the products | # Add update functionality within the products | ||
# Host site for serving package updates | # Host site for serving package updates | ||
# Develop common UI framework | # Develop common UI framework | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
Latest revision as of 16:22, 28 February 2012
This page discusses some long range plans for the Rifidi project.
Contents
Current State
Currently, the Rifidi products (Tag Streamer, and Emulator) are two 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:
- Two Separte Development Cycles for Rifidi 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 two separate, but related projects that are loosely-coupled
Solution through Service Oriented Architecture
In order to tie the two 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 'emulator' 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
