There are team sites within the rainbowportal.net where the coordinators of these teams can pretty much do whatever they want.  If you have some specific suggestions, and would like to do some of the work, please let me know what you want to do.
Your idea of 'tips' is a great one.  We can implement this very simply for now using the HTML module where we have pointers to original forum thread.  Please send me your list of tips and I will publish it. We also have 2 people working on a FAQ.
Mark McFarlane
-----Original Message-----
From: rainbowportal-devel-admin@lists.sourceforge.net [mailto:rainbowportal-devel-admin@lists.sourceforge.net] On Behalf Of yiming
Sent: Thursday, August 28, 2003 7:24 PM
To: rainbowportal-devel@lists.sourceforge.net
Subject: RE: [Rainbowportal-devel] My vision about next Rainbow. All people that want collaborate should read this. RE: to "Ideas about new DAL layer"

I'm happy to know you guys, even thou I'm just joined this team,
I had learned a lot from you guys. I have some vision on the original
IBS, and I found rainbow can realize it ( it's even better than my vision
in many ways). And I'm happy to see Manu's vision here, therefore
even I know that my skills is nothing to talk about here, but I still
dare to tell my ideas.

  1. Seperated but integrated:
    To seperate rainbow into smaller projects is necessary, but I hope that we can have a more stronger and common kernal between projects, especially to DAL. Even thou to let every divisioin into seperate parts is helpful, I till hope that modules can "talk" with each others, have a common DAL schema would be helpful for this(in my opnion). I have an idea, to let modules call others, I'll talk about this in the following points. And the most important is, to seperate rainbow is for more structive, the "unhappily" situation that manu talked about shouldn't happen again.
  2. Panes for design purpose:
    (Portals / Tabs / (panes) /Modules ), I think that we can make rainbow tree this way. But I don't mean that Pane is important, it's just for design purpose only. I believe 3 panes plus banner and footer can meet most of the requirement. But we can see that we need it to be more flexible. I'm thinking about several ways to improve this myself. I want to post another message to talk about this issue if nobody stops me (grin).
  3. Let the www.rainbowportal.net runs
    In fact, I think that we use "mail list" too much. There is a shortness about mail list archives, we can't reorgnize it easily. If we post our messages in our portal forums, maybe we can turn something into whitepapers easier.

    www.rainbowportal.net now seems much more like a "public relation" site, it let other people know rainbowportal better. But not help us who is working on it. I hope that we can have another site to let every teams have their own pages. And the coordinators or "page editors" and design some form to let people do or report their work on it. for example: If we add some new keys and remove some old keys, team coordinators can release them in the website, and let developers of localization working on their own parts. and every one can download the most update keys there. It's similar to the language_repl.mdb, but online.

    Generally, this developers site should be looked like MSDN site but built in Rainbow -- it's a resource repository. Developers can find things they want there, if editors find something great in the forums, they can
    also publish it into an official knowledge base item and give it a number. I'd like to be one of the editor members either myself.
  4. Modules Communication:
    I saw manu talked about "Intercommunication between modules", I think it's what I'm talking about generally.
    this is also an important part, I would like to describe my idea in another mail either. Basically, I hope it's similar to "web service", modules can transfer parameters to other modules, and have a mechanism like WSDL(but simpler, just a particular datastructure is enough) to get parameters needed by other modules.
  5. Official or hacking:
    When I'm trying to do something with rainbow, I felt that I'm "hacking" it. I don't mean trying to break rainbow's security, I mean find a place, doing something, and let it do something more then it's designed for.
    hacking is a good thing, to retrive more possibility of a software. they're also great tips that make software more useful. Maybe there should be a page about "rainbow tips", collect all the tips from forums, and might be turning them into official function sometimes.
  6. Way to Commercial:
    I don't know how will this be, rainbow should be always commercial"ABLE", or will limit it's possibility.
    And Commercialable is just the best part of the original IBS. In the other hand, if rainbow get "Too Commercial", it could be also limit usibility of rainbow. It's hard to handle with, in Chinese, we said it's "double sharp sides sword", it can be a weapon, but also could harm ourselves. I don't know how and what will be sell in the web. however, the free distributable rainbow should be full functional, and commercial modules should be "optional" and "enhanced". I remember there's a promise about rainbow itself will not be a "commercial version" of rainbow like MySQL. if there's a promise like that, I think any commercial module sould not break this promise.

    However, so if there will be commercial modules to be sell on the website, how will it be? It only sell "official commercial modules"? or it's just like "handango" for hand computing, to let developers sell modules here? or just like the control gallery of www.asp.net? Is there any rule of license ( one purchase for unlimited redistributed, or limit by domain/server)? For me, I prefer this to be a "trade platform" for all rainbow developers, these developers have better to be one of contributors also. rainbowportal can charge them for particular percents by each trade. Total price of each product have better not too high, from 30 too 300 USD, and they are better to be "one purchase, unlimited distributed". I think that since rainbow portal is based on open source platform, people should get paid from service clients more than making products.

How ever, it's just my opinion and response for manu's vision.