----- Original Message -----From: manuSent: Monday, August 25, 2003 10:10 AMSubject: [Rainbowportal-devel] My vision about next Rainbow. All people that want collaborate should read this. RE: to "Ideas about new DAL layer"
Hi all, and thanks to Jes for introducing some of my ideas.
This is the email that I promised some days ago. I receive many people that want collaborate and all should be subscribed to this list.
I will try to explain some “collaboration paths” in this mail so if you are interested in Rainbow developing you should read it.
First of all: all proposals in this mail apply to the next version (whatever it will be). Rainbow 1 is definitively closed. I will work on bug fixing and critical updates only.
Right now many different ideas coexist in Rainbow. Rainbow has grown really fast and some design flaws are mainly due to this fact. People have added many things to Rainbow to increase functionality. Unhappily, this process lacks a strong base design and, in the long run, this lead to bugs and difficulties in manageability.
So for next version I would like to change some things to improve manageability and possibly have a large developer base.
For now I do not want to speak about modules (Rainbow1 modules will work in v2 and later) because each module can have its own design (totally agree with Jes).
I would like to point out some ideas for the new framework.
I see Rainbow divided into the following areas:
- Structure (Portals / Tabs / Modules*) *from placement point of view, i.e. the rainbow tree.
- User / Roles / Groups management
- Design and Layout
- Modules (not part of this discussion)
The main idea behind this is: “Let’s move each of these areas into a separate DLL, implementing a well defined and, if possible, STANDARD (whatever that means ;-) ) set of interfaces”.
- Separate a large project into many smaller ones
- Each project has at least 2 Team Coordinators responsible for the project: one for managing people and public relations (documentation, quality assurance, bugs), one responsible for code, and 1 or more developers (coordinator may or may not be a developer).
- For each project is defined a set of Interfaces. Basing everything on Interfaces means that actual implementations are easily replaceable.
- Initial specifications of a project (i.e. Interfaces) are approved by this list (to avoid unpredicted or incompatible behaviours).
- Part of Interface definition will be clear documentation.
- Each Interface definition will provide a test suite (NUnit) that implementation teams will run on any implementation.
- Each test suite has a reference to the Interface and a progressive identification of subsequent versions.
- Tests can be upgraded from time to time, even if the Interface does not change. In this case the reference number should reflect this change. (A good reason for upgrading a test is a bug discovered in an implementation that the current test does not identify. Upgrading tests can help us to write good code using the experience of all interface implementers.)
- An implementation is defined as “compatible” with the specification if it can run all provided tests without errors. Compatibility must specify test version.
- Any important change to interface should be discussed in a central point in Rainbow because I could affect third part implementation and other components behaviour, implementation details are left to the team. If u agree, we can provide a trial schema to show how we see this.
- Many interface implementation can be available.
- Interface implementation can be written by teams other than main team or independent teams. This will lead to a more distributed development.
- Within their own organization, Rainbow developers may use a standard implementation or provide their own according to their specific needs.
- Specific implementations may be distributed in Rainbow main distribution, as downloadable DLL or sold as commercial components (for people who may concern…. we are planning to sell them directly from the rainbow portal website).
- Rainbow will became a more distributed effort (a collection of projects) rather than a single monolithic code block.
- When an interface is available accessing data directly is deprecated.
- A side effect of this is that we cannot speak about one DAL for rainbow. Each team can implement each own solution. Esperantus has already an independent layer, interface based. This can be really helpful because upgrades can move in small steps and the whole project should not be affected (we can upgrade the Esperantus layer without affecting user profiles. At some point we will define some “best practices” for new project but these will be simple “advices” and not “must do” as far as the system works ;-) .
All these task can be divided among many people in a big project or done by a single person in a small one. Anyway I prefer having small teams with specific, small tasks. These are only suggestions and lessons learned. Any advice is welcome. I know that many of you have a lot of experience in this field so any contribution is really welcome. I hope this will lead at some point to a guidelines document.
HUMAN COORDINATOR TASKS
- Decide the maximum number of people involved in a specific project.
- Decide the procedure for accepting new members and for leaving the team.
- Manage new members that want participate and members that want to leave.
- Contact on regular basis team members to ensure progress.
- Know all members involved at any given time and how much they are involved. Know how many hours per week each developer can assure.
- Move specific tasks from one developer to another based on individual available time.
- Regularly read and reply to project forum. Forward specific issues to the responsible person(s) if something needs attention.
- Define which quality goals must be met for a release and verify that any new release complies with it.
- Revise documentation.
If you are good at managing people and tasks (no C# or programming competence needed) you can help with organization - we need you!. More experienced people can be coordinators. Others can simply help the main coordinator in some tasks.
TECHNICAL COORDINATOR TASKS
- Coordinate ideas in whitepapers and interface definitions.
- Scan newsgroups, lists and internet in general to collect new ideas for later review with other team members.
- Ensure that all jobs done by programmers comply with initial goals and requirements.
- Ensure that a certain number of bugs are fixed before adding new features.
- Ensure deadlines are met.
- Manage support requests if applicable (this can be part of bug fixing cycle).
- Revise code.
If you know ASP.NET plus C# and you can guarantee a couple of hour per week you can contribute as a coder. More experienced people can be coordinators (coordinators should ensure at least 5 hours per week in a big project) or help coordinators in some tasks (if you have less time).
Whatever your ability is there are many things to do in Rainbow projects. Space is available for all. Just contact the project coordinator and propose your ideas. The only thing required is happiness and enthusiasm!
I have started on a practical level to do most of these things in Esperantus. All code that manages localization was moved there. Interfaces are defined for accessing keys. Some implementations are provided. Other can be plugged using classes or web.config. A suite of tests is defined as well. (Latest code is available at: http://sourceforge.net/projects/esperantus). Basically Esperantus proves that all these goals are valid tested. I only need some more collaboration. I see in this list there are many people that want collaborate: this is the way!
The basic goal of this is to have always a responsible to contact for each project.
So, what for the future?
I want to start 2 projects soon:
- One for managing users. This will define interfaces for users (including profiling), roles and groups. This will define interfaces for permissions as well. Both Forms and Windows authentication will be supported. (note: Much work has been done in this area. Read Security whitepaper in archive). Some people are interested in this. More details are collected by Mark in a forum thread at: http://www.rainbowportal.net/AspNetForums/ShowPost.aspx?PostID=3320#4066 – some code and interface are already coded by Geert.
- One for redefining the Rainbow structure. Basically Portal Data, Tabs Tree will go there. This project will define the standard way to interact with the Rainbow tree. This could affect some modules that now access data directly (e.g.: MenuNavigation or Breadcrumbs). I have some come ready to discuss.
Now the questions are:
- Do you agree with the goals proposed (generally speaking)?
- Speaking about specific projects I need at least two people for each project. I can follow as coordinator one of them (Technical). So I need at least 3 people for starting both projects. Both project require other people that can code and develop specific tasks. Who wants to help?
Additional projects are (this is not a comprehensive list, only some project that I remember at moment. Any other idea is welcome.):
- Esperantus (It is almost stable right now. A couple of people that want to follow it would be greatly appreciated. This refers to code and not to localization effort, this one is a specific, different project.)
- ICATS as proposed by Jackobs (see archive)
- Design (Layouts, Theme, integration with VS 2004), maybe more than one project.
- Persistence layer. A standard interface for storing items (files). Providing at least 2 implementations: to file system, to db (web farm support). (Cory started something like that mimic the File and Directory classes.)
- Intercommunication between modules: http://aspalliance.com/bbilbro/DesktopDefault.aspx?tabindex=1&tabid=7&ArticleID=6
- Other projects like Scheduler, Monitor, and more to come… these are only some ideas.
Emmanuele De Andreis
Internet Solutions Provider
Da: email@example.com [mailto:firstname.lastname@example.org] Per conto di Jeremy Esland
Inviato: venerdì 22 agosto 2003 20.26
A: email@example.com; 'Rainbow developer'
Oggetto: RE: [Rainbowportal-devel] Ideas about new DAL layer
Let me play the Devil’s Advocate… I believe we should separate in our minds, in these discussions, and indeed in code, the data requirements of the Rainbow portal framework itself, and the data requirements of any particular module. They are different, unrelated, etc. – so let’s treat them that way. Indeed, there are strong architectural reasons why they should be separated – but I’m going to assume that everyone will agree with me on that point and not waste your time reading my supporting argument for it.
So… Rainbow’s “framework data” – what is it? A collection of data describing portals/tabs/modules and users. User data is a separate issue, so let’s actually divide Rainbow’s total data requirements into three:
1. framework data
2. user data
3. module data
Examining the characteristics of each of these data requirements, we find that framework data (portals/tabs/module settings, etc) is mostly hierarchical in nature, rather than relational; user data is more closely related to module data than it is to framework data; and module data is open-ended – sometimes flat, sometimes relational, sometimes hierarchical. In terms of access/edit frequency and performance requirements, framework data would be better off in memory at all times; user data access is “occasional” and not performance-sensitive; and module data should live in memory unless there’s a very good reason to be reading it in real-time. Again, I’ll spare you the long-winded argument behind these statements, but by all means disagree with them. So the challenge is to build three data access solutions, not one. Each solution should be optimised to its task and the demands that will be made of it.
Framework data will be dealt with entirely within the Rainbow core – not particular need for fancy developer-friendly DAL stuff there – the core can offer a range of backend options, each of which may or may not support farming, but how it’s implemented internally is of no interest outside the ring of core developers.
User data is one of our big weaknesses at the moment – it needs to be flexible and extensible. In many cases it will also need to be shared with other applications. We need a desperately clever solution here but, again, it’s a “one-off” exercise with no particular requirement for code-level friendliness.
Module data. Well, forgive me if you disagree with me on this, but I really do think that the subject is too broad and too unknown for us to be discussing it in acronym-heavy specifics. Certainly we cannot assume that a relational store is always suitable. Certainly we cannot assume that a single store is always suitable. Certainly we cannot assume that Rainbow has any more than read-only access to the data. In fact, we shouldn’t even assume that the data is available!
To use an analogy, I believe we are discussing the dimensions and composition of bricks when we should still be talking to the architect.
PS: I managed to write all of that without once mentioning XML! My psychiatrist will be so pleased!