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:
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”.
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
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
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:
Now the questions are:
Additional projects are (this is not a comprehensive list, only some project that I remember at moment. Any other idea is welcome.):
Emmanuele De Andreis
Internet Solutions Provider
Da: firstname.lastname@example.org [mailto:email@example.com] Per conto di Jeremy Esland
Inviato: venerd́ 22 agosto 2003 20.26
A: firstname.lastname@example.org; '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!