Thread: [Rainbowportal-devel] Rainbow team news
Brought to you by:
danijel_kecman,
manudea
From: manu <ma...@du...> - 2003-08-19 11:04:15
|
Hi folks, so many news and so little time to handle. I'm finally back at work after vacations and I have tons of things to = handle before all would fine. Anyway Rainbow is growing and I want to really thank all people involved = in this big adventure. Some news are in marketing and strategy, I will come with details next = week. =20 Some good news. First: Rainbow was reviewed on top Italian financial newspaper (Il sole = 24 ore) on 24 jul 2003, just let list know about it. =20 Another good news: Mike Upshon, the creator of Kickstarter want help us. Register to http://beta.kickstarter.net/Default.aspx and get the latest copy. I have tried it and I think it is great. It is a code/dal generator and it is especially useful for building data/driven modules.=20 Code generated is royalty free and can be distributed as open source or = for paying. It is a commercial product but Mike should made it available the final version for free to rainbow contributors. Have a look and try it. It is in free test until the end of month. =20 Another proposal was Simplido, you can find more info http://www.izenda.com/Izenda/Page.aspx?content=3DSimplido37 The bad side of it is that is a product that will be licensed only for Rainbow use (you cannot use in other projects without paying a license) = and would be a core component not open source. Anyway have a look at it. =20 I hope to quickly find time to reply to other mails. =20 Sincerely. =20 ------------------------------------ Emmanuele De Andreis Technical Manager DUEMETRI Internet Solutions Provider RAINBOW PORTAL Main portal - http://www.rainbowportal.net = <http://www.rainbowportal.net/>=20 Sourceforge CVS - http://sourceforge.net/projects/rainbowportal/ Support Forums - http://www.rainbowportal.net/ASPNetForums Bug Tracker - http://sourceforge.net/tracker/?group_id=3D66837 <http://sourceforge.net/tracker/?group_id=3D66837&atid=3D515929> = &atid=3D515929 =20 |
From: Federico D. M. <if...@li...> - 2003-08-19 13:59:57
|
I want to write some ideas about a new structure for Rainbow Data Access LAyer and more. Perhaps it maybe adopted in Rainbow 2 I think that data access architecture in current Rainbow version has 3 big problems: 1. It is strongly linked to SQL Server 2. It is strongly linked to Module (Rainbow database structure is generated by module installation. Each module create its table, stored procedure and so on. For example if I want to create a new news module with some new features I have to create a new table for news and I cannot use and share my data with exist old news module. Because I must suppose that a new version of old module would change its db structure. On the other hand it's hard to create a new graphic interface for a exist news module) 3. It doesn't allow a simple OOP programming approach to Module programmer The best way to solve these problems would be a O/R mapper data access architecture like the java EJB or Hibernate. But the .NET portings of these mappers are currently in alpha stage. The NHibernate leader is missing (!) and project is stopping now. The OJB project is still in pre-alpha stage. So, I think we will not be able to play with a stable O/R mapper in the next months and we will not program in pure OOP in every layer till next year... To solve the 3 problems above I suggest to introduce in Rainbow system: A. a new module data layer B. a interface based (or abstract class based) data access layer The new architecture (i.e. for news) maybe connected like this graph UINewsModule1 UINewsModule2 UINewsModule3 | | | +-------+-------+ | | | FedeDataNewsModule ManuDataNewsModule | | +---------+------------+ | AbstractDALlayer | | Database A DataModule is a installable non-graphic module the expose a standard interface for UIModules and on the other side calls the AbstractDataAccessLayer. For example the FedeDataNewsModule could expose methods like: int AddNews(title, userId, text, expirationDate) void DeleteNews(int newsId) FedeNews[] GetThreeTopClickedNews(int newsCategoryId) ... ManuDataNewsModule could expose different methods. (Not IDataReader or IDataSet are passed to UIModule!) FedeDataNewsModule call AbstractDALLayer methods to perform actions in ITS db table ManuDataNewsModule call AbstractDALLayer methods to perform actions in ITS db table (usually different from FedeTables) The UINewsModuleX is standard rainbow graphics module that use methods expose by middle DataModule who it's linked to. They ignore the existance of database. The UINewsModule1 and UINewsModule2 is located in different pages and have a different graphics structure and different user interface and behavior, BUT they CAN modify the same set of news. Using this architecture we can build a dynamic easy to understand structure of site contents: For example: MySite | +-News (provided by FedeDataNewsModule) | | | +-Business news | | +- publ. in HomePage using UINewsModule1 | | +- publ. in ShoppingPage using UINewsModule2 | | | +-Customer news | +- publ. in WelcomeCustomer using UINewsModule2 | +-News (provided by ManuDataNewsModule) | | | +-Company news | +- publ. in InternalHomePage using UINewsModule3 | +-Forums (provided by ACMEDataForumModule) | | | +-Open discussion forum | | +- publ. in DiscussionPage using HyperBitIncForumsModule | | | . . . . . . Each graphic module is linked to a specific type of data source module. The installation process would be easy: if I install a new UImodule and his DataModules (maybe more than one) don't exist the they will be installed too. I think this approach wuold be simplify our work. UIModule will be more powerful, easier to create and db neutral. We could think to create some UIModule specialized in data managed for a specific DataModule, and so on... The AbstractDAL is responsible of db neutral access. The DataModule create SQL generic instruction and obtain IDataSet, IDataReader object. I know this is not good like a SQL-Server stored procedure, but the system can be extended to other database, and if in the future we will have a O/R mapper we will have to modify only the database interface of DataModule and nothing in UIModules. I think that DAAB is a good first step for AbstractDAL. Fede_ |
From: Geert A. <Gee...@sy...> - 2003-08-19 14:19:55
|
Hi Federico, Do you really need a database at all? When you create a nice object model, you can serialize it and just save it to disk. You can host the entry point to this object model as a singleton (via .NET Remoting) in rainbow itself. This way it only has to be instantiated once, when the portal website is started. It works great and its faster then database access. This is also the way MS CMS works, the only difference is, that they serialize it to sql server, just to self their dbms. I recently developed a small web application like this, and it works great! Just a thought, Greetz, Geert **************** Geert Audenaert Syntegra has moved! Please find hereunder our new contact details Address: Telecomlaan 9 at 1831 Diegem General Telephone Number: +32 (0)2 700 30 11 General Fax Number: +32 (0)2 700 30 12 E-mail: in...@sy... Internet: www.syntegra.com **************** -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of Federico Dal Maso Sent: dinsdag 19 augustus 2003 16:01 To: Rainbow developer Subject: [Rainbowportal-devel] Ideas about new DAL layer I want to write some ideas about a new structure for Rainbow Data Access LAyer and more. Perhaps it maybe adopted in Rainbow 2 I think that data access architecture in current Rainbow version has 3 big problems: 1. It is strongly linked to SQL Server 2. It is strongly linked to Module (Rainbow database structure is generated by module installation. Each module create its table, stored procedure and so on. For example if I want to create a new news module with some new features I have to create a new table for news and I cannot use and share my data with exist old news module. Because I must suppose that a new version of old module would change its db structure. On the other hand it's hard to create a new graphic interface for a exist news module) 3. It doesn't allow a simple OOP programming approach to Module programmer The best way to solve these problems would be a O/R mapper data access architecture like the java EJB or Hibernate. But the .NET portings of these mappers are currently in alpha stage. The NHibernate leader is missing (!) and project is stopping now. The OJB project is still in pre-alpha stage. So, I think we will not be able to play with a stable O/R mapper in the next months and we will not program in pure OOP in every layer till next year... To solve the 3 problems above I suggest to introduce in Rainbow system: A. a new module data layer B. a interface based (or abstract class based) data access layer The new architecture (i.e. for news) maybe connected like this graph UINewsModule1 UINewsModule2 UINewsModule3 | | | +-------+-------+ | | | FedeDataNewsModule ManuDataNewsModule | | +---------+------------+ | AbstractDALlayer | | Database A DataModule is a installable non-graphic module the expose a standard interface for UIModules and on the other side calls the AbstractDataAccessLayer. For example the FedeDataNewsModule could expose methods like: int AddNews(title, userId, text, expirationDate) void DeleteNews(int newsId) FedeNews[] GetThreeTopClickedNews(int newsCategoryId) ... ManuDataNewsModule could expose different methods. (Not IDataReader or IDataSet are passed to UIModule!) FedeDataNewsModule call AbstractDALLayer methods to perform actions in ITS db table ManuDataNewsModule call AbstractDALLayer methods to perform actions in ITS db table (usually different from FedeTables) The UINewsModuleX is standard rainbow graphics module that use methods expose by middle DataModule who it's linked to. They ignore the existance of database. The UINewsModule1 and UINewsModule2 is located in different pages and have a different graphics structure and different user interface and behavior, BUT they CAN modify the same set of news. Using this architecture we can build a dynamic easy to understand structure of site contents: For example: MySite | +-News (provided by FedeDataNewsModule) | | | +-Business news | | +- publ. in HomePage using UINewsModule1 | | +- publ. in ShoppingPage using UINewsModule2 | | | +-Customer news | +- publ. in WelcomeCustomer using UINewsModule2 | +-News (provided by ManuDataNewsModule) | | | +-Company news | +- publ. in InternalHomePage using UINewsModule3 | +-Forums (provided by ACMEDataForumModule) | | | +-Open discussion forum | | +- publ. in DiscussionPage using HyperBitIncForumsModule | | | . . . . . . Each graphic module is linked to a specific type of data source module. The installation process would be easy: if I install a new UImodule and his DataModules (maybe more than one) don't exist the they will be installed too. I think this approach wuold be simplify our work. UIModule will be more powerful, easier to create and db neutral. We could think to create some UIModule specialized in data managed for a specific DataModule, and so on... The AbstractDAL is responsible of db neutral access. The DataModule create SQL generic instruction and obtain IDataSet, IDataReader object. I know this is not good like a SQL-Server stored procedure, but the system can be extended to other database, and if in the future we will have a O/R mapper we will have to modify only the database interface of DataModule and nothing in UIModules. I think that DAAB is a good first step for AbstractDAL. Fede_ ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01 /01 _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel |
From: Cory I. <cis...@ya...> - 2003-08-20 03:36:06
|
Geert, I beleive you are thinking similiar to me. The problem with not storing the object in the DB is that those of use using web server farms would have difficulty keeping everything in sync if it was stored on disk. We would need a DB or some other solution for storing the data in a central location. I beleive that scalability of web farms would be the reason that MS CMS uses SQL for storage. We all know they want to promote SQL server, but most any DB could be used to store serialized objects. One other problem with the serialized objects is that they cannot be searched or indexed as easilly as regular database items. I think there needs to be some balance between the central storage of data and web server data caching in memory/disk. Cory Geert Audenaert <Gee...@sy...> wrote: Hi Federico, Do you really need a database at all? When you create a nice object model, you can serialize it and just save it to disk. You can host the entry point to this object model as a singleton (via .NET Remoting) in rainbow itself. This way it only has to be instantiated once, when the portal website is started. It works great and its faster then database access. This is also the way MS CMS works, the only difference is, that they serialize it to sql server, just to self their dbms. I recently developed a small web application like this, and it works great! Just a thought, Greetz, Geert **************** Geert Audenaert Syntegra has moved! Please find hereunder our new contact details Address: Telecomlaan 9 at 1831 Diegem General Telephone Number: +32 (0)2 700 30 11 General Fax Number: +32 (0)2 700 30 12 E-mail: in...@sy... Internet: www.syntegra.com **************** -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of Federico Dal Maso Sent: dinsdag 19 augustus 2003 16:01 To: Rainbow developer Subject: [Rainbowportal-devel] Ideas about new DAL layer I want to write some ideas about a new structure for Rainbow Data Access LAyer and more. Perhaps it maybe adopted in Rainbow 2 I think that data access architecture in current Rainbow version has 3 big problems: 1. It is strongly linked to SQL Server 2. It is strongly linked to Module (Rainbow database structure is generated by module installation. Each module create its table, stored procedure and so on. For example if I want to create a new news module with some new features I have to create a new table for news and I cannot use and share my data with exist old news module. Because I must suppose that a new version of old module would change its db structure. On the other hand it's hard to create a new graphic interface for a exist news module) 3. It doesn't allow a simple OOP programming approach to Module programmer The best way to solve these problems would be a O/R mapper data access architecture like the java EJB or Hibernate. But the .NET portings of these mappers are currently in alpha stage. The NHibernate leader is missing (!) and project is stopping now. The OJB project is still in pre-alpha stage. So, I think we will not be able to play with a stable O/R mapper in the next months and we will not program in pure OOP in every layer till next year... To solve the 3 problems above I suggest to introduce in Rainbow system: A. a new module data layer B. a interface based (or abstract class based) data access layer The new architecture (i.e. for news) maybe connected like this graph UINewsModule1 UINewsModule2 UINewsModule3 | | | +-------+-------+ | | | FedeDataNewsModule ManuDataNewsModule | | +---------+------------+ | AbstractDALlayer | | Database A DataModule is a installable non-graphic module the expose a standard interface for UIModules and on the other side calls the AbstractDataAccessLayer. For example the FedeDataNewsModule could expose methods like: int AddNews(title, userId, text, expirationDate) void DeleteNews(int newsId) FedeNews[] GetThreeTopClickedNews(int newsCategoryId) ... ManuDataNewsModule could expose different methods. (Not IDataReader or IDataSet are passed to UIModule!) FedeDataNewsModule call AbstractDALLayer methods to perform actions in ITS db table ManuDataNewsModule call AbstractDALLayer methods to perform actions in ITS db table (usually different from FedeTables) The UINewsModuleX is standard rainbow graphics module that use methods expose by middle DataModule who it's linked to. They ignore the existance of database. The UINewsModule1 and UINewsModule2 is located in different pages and have a different graphics structure and different user interface and behavior, BUT they CAN modify the same set of news. Using this architecture we can build a dynamic easy to understand structure of site contents: For example: MySite | +-News (provided by FedeDataNewsModule) | | | +-Business news | | +- publ. in HomePage using UINewsModule1 | | +- publ. in ShoppingPage using UINewsModule2 | | | +-Customer news | +- publ. in WelcomeCustomer using UINewsModule2 | +-News (provided by ManuDataNewsModule) | | | +-Company news | +- publ. in InternalHomePage using UINewsModule3 | +-Forums (provided by ACMEDataForumModule) | | | +-Open discussion forum | | +- publ. in DiscussionPage using HyperBitIncForumsModule | | | . . . . . . Each graphic module is linked to a specific type of data source module. The installation process would be easy: if I install a new UImodule and his DataModules (maybe more than one) don't exist the they will be installed too. I think this approach wuold be simplify our work. UIModule will be more powerful, easier to create and db neutral. We could think to create some UIModule specialized in data managed for a specific DataModule, and so on... The AbstractDAL is responsible of db neutral access. The DataModule create SQL generic instruction and obtain IDataSet, IDataReader object. I know this is not good like a SQL-Server stored procedure, but the system can be extended to other database, and if in the future we will have a O/R mapper we will have to modify only the database interface of DataModule and nothing in UIModules. I think that DAAB is a good first step for AbstractDAL. Fede_ ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01 /01 _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel Cory Isakson Online Status: --------------------------------- 3.9 Cents/min. No Fees or Minimums! http://www.dial4life.com --------------------------------- --------------------------------- Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software |
From: Jeremy E. <es...@ma...> - 2003-08-22 18:26:00
|
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. Jes1111 PS: I managed to write all of that without once mentioning XML! My psychiatrist will be so pleased! -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of Cory Isakson Sent: 19 August 2003 15:34 To: 'Rainbow developer' Subject: RE: [Rainbowportal-devel] Ideas about new DAL layer Geert, I beleive you are thinking similiar to me. The problem with not storing the object in the DB is that those of use using web server farms would have difficulty keeping everything in sync if it was stored on disk. We would need a DB or some other solution for storing the data in a central location. I beleive that scalability of web farms would be the reason that MS CMS uses SQL for storage. We all know they want to promote SQL server, but most any DB could be used to store serialized objects. One other problem with the serialized objects is that they cannot be searched or indexed as easilly as regular database items. I think there needs to be some balance between the central storage of data and web server data caching in memory/disk. Cory Geert Audenaert <Gee...@sy...> wrote: Hi Federico, Do you really need a database at all? When you create a nice object model, you can serialize it and just save it to disk. You can host the entry point to this object model as a singleton (via .NET Remoting) in rainbow itself. This way it only has to be instantiated once, when the portal website is started. It works great and its faster then database access. This is also the way MS CMS works, the only difference is, that they serialize it to sql server, just to self their dbms. I recently developed a small web application like this, and it works great! Just a thought, Greetz, Geert **************** Geert Audenaert Syntegra has moved! Please find hereunder our new contact details Address: Telecomlaan 9 at 1831 Diegem General Telephone Number: +32 (0)2 700 30 11 General Fax Number: +32 (0)2 700 30 12 E-mail: in...@sy... Internet: www.syntegra.com **************** -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of Federico Dal Maso Sent: dinsdag 19 augustus 2003 16:01 To: Rainbow developer Subject: [Rainbowportal-devel] Ideas about new DAL layer I want to write some ideas about a new structure for Rainbow Data Access LAyer and more. Perhaps it maybe adopted in Rainbow 2 I think that data access architecture in current Rainbow version has 3 big problems: 1. It is strongly linked to SQL Server 2. It is strongly linked to Module (Rainbow database structure is generated by module installation. Each module create its table, stored procedure and so on. For example if I want to create a new news module with some new features I have to create a new table for news and I cannot use and share my data with exist old news module. Because I must suppose that a new version of old module would change its db structure. On the other hand it's hard to create a new graphic interface for a exist news module) 3. It doesn't allow a simple OOP programming approach to Module programmer The best way to solve these problems would be a O/R mapper data access architecture like the java EJB or Hibernate. But the .NET portings of these mappers are currently in alpha stage. The NHibernate leader is missing (!) and project is stopping now. The OJB project is still in pre-alpha stage. So, I think we will not be able to play with a stable O/R mapper in the next months and we will not program in pure OOP in every layer till next year... To solve the 3 problems above I suggest to introduce in Rainbow system: A. a new module data layer B. a interface based (or abstract class based) data access layer The new architecture (i.e. for news) maybe connected like this graph UINewsModule1 UINewsModule2 UINewsModule3 | | | +-------+-------+ | | | FedeDataNewsModule ManuDataNewsModule | | +---------+------------+ | AbstractDALlayer | | Database A DataModule is a installable non-graphic module the expose a standard interface for UIModules and on the other side calls the AbstractDataAccessLayer. For example the FedeDataNewsModule could expose methods like: int AddNews(title, userId, text, expirationDate) void DeleteNews(int newsId) FedeNews[] GetThreeTopClickedNews(int newsCategoryId) ... ManuDataNewsModule could expose different methods. (Not IDataReader or IDataSet are passed to UIModule!) FedeDataNewsModule call AbstractDALLayer methods to perform actions in ITS db table ManuDataNewsModule call AbstractDALLayer methods to perform actions in ITS db table (usually different from FedeTables) The UINewsModuleX is standard rainbow graphics module that use methods expose by middle DataModule who it's linked to. They ignore the existance of database. The UINewsModule1 and UINewsModule2 is located in different pages and have a different graphics structure and different user interface and behavior, BUT they CAN modify the same set of news. Using this architecture we can build a dynamic easy to understand structure of site contents: For example: MySite | +-News (provided by FedeDataNewsModule) | | | +-Business news | | +- publ. in HomePage using UINewsModule1 | | +- publ. in ShoppingPage using UINewsModule2 | | | +-Customer news | +- publ. in WelcomeCustomer using UINewsModule2 | +-News (provided by ManuDataNewsModule) | | | +-Company news | +- publ. in InternalHomePage using UINewsModule3 | +-Forums (provided by ACMEDataForumModule) | | | +-Open discussion forum | | +- publ. in DiscussionPage using HyperBitIncForumsModule | | | . . . . . . Each graphic module is linked to a specific type of data source module. The installation process would be easy: if I install a new UImodule and his DataModules (maybe more than one) don't exist the they will be installed too. I think this approach wuold be simplify our work. UIModule will be more powerful, easier to create and db neutral. We could think to create some UIModule specialized in data managed for a specific DataModule, and so on... The AbstractDAL is responsible of db neutral access. The DataModule create SQL generic instruction and obtain IDataSet, IDataReader object. I know this is not good like a SQL-Server stored procedure, but the system can be extended to other database, and if in the future we will have a O/R mapper we will have to modify only the database interface of DataModule and nothing in UIModules. I think that DAAB is a good first step for AbstractDAL. Fede_ ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01 /01 _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01 /01 _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel Cory Isakson Online Status: <http://www.lifelesspeople.com:4000/message/msn/cis...@ya...> Online Status Indicator <aim:goim?screenname=cwisakson> _____ 3.9 Cents/min. No Fees or Minimums! http://www.dial4life.com <http://ld.net/?dial4life> _____ _____ Do you Yahoo!? Yahoo! <http://us.rd.yahoo.com/evt=10469/*http:/sitebuilder.yahoo.com> SiteBuilder - Free, easy-to-use web site design software |
From: Geert A. <Gee...@sy...> - 2003-08-25 17:36:19
|
I couldn't have written it better. The reason I started this discussion, is because I think there is far too much database access in our current solution. I did a small test and removed all the database calls for what Jeremy calls "framework related data". I replaced the data that originally came from the database with default data coming from a small serialized object model stored in the cache object. It speeded up my test site by 20x times. If you examine the framework code, you'll see that for every request a huge number of times the database is accessed. If we could eliminate these database requests, we also put less pressure on the database system. Greetz, Geert **************** Geert Audenaert Syntegra has moved! Please find hereunder our new contact details Address: Telecomlaan 9 at 1831 Diegem General Telephone Number: +32 (0)2 700 30 11 General Fax Number: +32 (0)2 700 30 12 E-mail: <mailto:in...@sy...> in...@sy... Internet: <http://www.syntegra.com> www.syntegra.com **************** -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of Jeremy Esland Sent: vrijdag 22 augustus 2003 20:26 To: cis...@ya...; 'Rainbow developer' Subject: 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. Jes1111 PS: I managed to write all of that without once mentioning XML! My psychiatrist will be so pleased! -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of Cory Isakson Sent: 19 August 2003 15:34 To: 'Rainbow developer' Subject: RE: [Rainbowportal-devel] Ideas about new DAL layer Geert, I beleive you are thinking similiar to me. The problem with not storing the object in the DB is that those of use using web server farms would have difficulty keeping everything in sync if it was stored on disk. We would need a DB or some other solution for storing the data in a central location. I beleive that scalability of web farms would be the reason that MS CMS uses SQL for storage. We all know they want to promote SQL server, but most any DB could be used to store serialized objects. One other problem with the serialized objects is that they cannot be searched or indexed as easilly as regular database items. I think there needs to be some balance between the central storage of data and web server data caching in memory/disk. Cory Geert Audenaert <Gee...@sy...> wrote: Hi Federico, Do you really need a database at all? When you create a nice object model, you can serialize it and just save it to disk. You can host the entry point to this object model as a singleton (via .NET Remoting) in rainbow itself. This way it only has to be instantiated once, when the portal website is started. It works great and its faster then database access. This is also the way MS CMS works, the only difference is, that they serialize it to sql server, just to self their dbms. I recently developed a small web application like this, and it works great! Just a thought, Greetz, Geert **************** Geert Audenaert Syntegra has moved! Please find hereunder our new contact details Address: Telecomlaan 9 at 1831 Diegem General Telephone Number: +32 (0)2 700 30 11 General Fax Number: +32 (0)2 700 30 12 E-mail: in...@sy... Internet: www.syntegra.com **************** -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of Federico Dal Maso Sent: dinsdag 19 augustus 2003 16:01 To: Rainbow developer Subject: [Rainbowportal-devel] Ideas about new DAL layer I want to write some ideas about a new structure for Rainbow Data Access LAyer and more. Perhaps it maybe adopted in Rainbow 2 I think that data access architecture in current Rainbow version has 3 big problems: 1. It is strongly linked to SQL Server 2. It is strongly linked to Module (Rainbow database structure is generated by module installation. Each module create its table, stored procedure and so on. For example if I want to create a new news module with some new features I have to create a new table for news and I cannot use and share my data with exist old news module. Because I must suppose that a new version of old module would change its db structure. On the other hand it's hard to create a new graphic interface for a exist news module) 3. It doesn't allow a simple OOP programming approach to Module programmer The best way to solve these problems would be a O/R mapper data access architecture like the java EJB or Hibernate. But the .NET portings of these mappers are currently in alpha stage. The NHibernate leader is missing (!) and project is stopping now. The OJB project is still in pre-alpha stage. So, I think we will not be able to play with a stable O/R mapper in the next months and we will not program in pure OOP in every layer till next year... To solve the 3 problems above I suggest to introduce in Rainbow system: A. a new module data layer B. a interface based (or abstract class based) data access layer The new architecture (i.e. for news) maybe connected like this graph UINewsModule1 UINewsModule2 UINewsModule3 | | | +-------+-------+ | | | FedeDataNewsModule ManuDataNewsModule | | +---------+------------+ | AbstractDALlayer | | Database A DataModule is a installable non-graphic module the expose a standard interface for UIModules and on the other side calls the AbstractDataAccessLayer. For example the FedeDataNewsModule could expose methods like: int AddNews(title, userId, text, expirationDate) void DeleteNews(int newsId) FedeNews[] GetThreeTopClickedNews(int newsCategoryId) ... ManuDataNewsModule could expose different methods. (Not IDataReader or IDataSet are passed to UIModule!) FedeDataNewsModule call AbstractDALLayer methods to perform actions in ITS db table ManuDataNewsModule call AbstractDALLayer methods to perform actions in ITS db table (usually different from FedeTables) The UINewsModuleX is standard rainbow graphics module that use methods expose by middle DataModule who it's linked to. They ignore the existance of database. The UINewsModule1 and UINewsModule2 is located in different pages and have a different graphics structure and different user interface and behavior, BUT they CAN modify the same set of news. Using this architecture we can build a dynamic easy to understand structure of site contents: For example: MySite | +-News (provided by FedeDataNewsModule) | | | +-Business news | | +- publ. in HomePage using UINewsModule1 | | +- publ. in ShoppingPage using UINewsModule2 | | | +-Customer news | +- publ. in WelcomeCustomer using UINewsModule2 | +-News (provided by ManuDataNewsModule) | | | +-Company news | +- publ. in InternalHomePage using UINewsModule3 | +-Forums (provided by ACMEDataForumModule) | | | +-Open discussion forum | | +- publ. in DiscussionPage using HyperBitIncForumsModule | | | . . . . . . Each graphic module is linked to a specific type of data source module. The installation process would be easy: if I install a new UImodule and his DataModules (maybe more than one) don't exist the they will be installed too. I think this approach wuold be simplify our work. UIModule will be more powerful, easier to create and db neutral. We could think to create some UIModule specialized in data managed for a specific DataModule, and so on... The AbstractDAL is responsible of db neutral access. The DataModule create SQL generic instruction and obtain IDataSet, IDataReader object. I know this is not good like a SQL-Server stored procedure, but the system can be extended to other database, and if in the future we will have a O/R mapper we will have to modify only the database interface of DataModule and nothing in UIModules. I think that DAAB is a good first step for AbstractDAL. Fede_ ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01 /01 _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01 /01 _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel Cory Isakson Online Status: <http://www.lifelesspeople.com:4000/message/msn/cis...@ya...> Online Status Indicator <aim:goim?screenname=cwisakson> _____ 3.9 Cents/min. No Fees or Minimums! http://www.dial4life.com <http://ld.net/?dial4life> _____ _____ Do you Yahoo!? Yahoo! SiteBuilder <http://us.rd.yahoo.com/evt=10469/*http:/sitebuilder.yahoo.com> - Free, easy-to-use web site design software |
From: manu <ma...@du...> - 2003-08-26 02:33:52
|
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 =93collaboration paths=94 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 * Permissions * Design and Layout * Globalization * Modules (not part of this discussion) The main idea behind this is: =93Let=92s move each of these areas into a separate DLL, implementing a well defined and, if possible, STANDARD (whatever that means ;-) ) set of interfaces=94. Some goals: * 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 =93compatible=94 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=85. 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.=20 * 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 =93best practices=94 for new = project but these will be simple =93advices=94 and not =93must do=94 as far as = the system works ;-) . =20 COORDINATOR TASKS 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=20 * 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. HELPING COORDINATION 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.=20 * Manage support requests if applicable (this can be part of bug fixing cycle). * Revise code. CODER 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). HELPER 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=3D3320#406= 6 =96 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: 1. Do you agree with the goals proposed (generally speaking)? 2. 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?=20 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.) * Ecommerce * 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=3D1 <http://aspalliance.com/bbilbro/DesktopDefault.aspx?tabindex=3D1&tabid=3D= 7&Artic leID=3D6> &tabid=3D7&ArticleID=3D6 * Other projects like Scheduler, Monitor, and more to come=85 these are only some ideas.=20 Sincerely Manu =20 ------------------------------------ Emmanuele De Andreis Technical Manager DUEMETRI Internet Solutions Provider RAINBOW PORTAL Main portal - http://www.rainbowportal.net = <http://www.rainbowportal.net/>=20 Sourceforge CVS - http://sourceforge.net/projects/rainbowportal/ Support Forums - http://www.rainbowportal.net/ASPNetForums Bug Tracker - http://sourceforge.net/tracker/?group_id=3D66837 <http://sourceforge.net/tracker/?group_id=3D66837&atid=3D515929> = &atid=3D515929 =20 -----Messaggio originale----- Da: rai...@li... [mailto:rai...@li...] Per conto di = Jeremy Esland Inviato: venerd=EC 22 agosto 2003 20.26 A: cis...@ya...; 'Rainbow developer' Oggetto: RE: [Rainbowportal-devel] Ideas about new DAL layer =20 Let me play the Devil=92s Advocate=85 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. =96 so let=92s treat them = that way. Indeed, there are strong architectural reasons why they should be = separated =96 but I=92m going to assume that everyone will agree with me on that = point and not waste your time reading my supporting argument for it. =20 So=85 Rainbow=92s =93framework data=94 =96 what is it? A collection of = data describing portals/tabs/modules and users. User data is a separate issue, so = let=92s actually divide Rainbow=92s total data requirements into three: =20 1. framework data 2. user data 3. module data =20 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 =96 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 =93occasional=94 and not performance-sensitive; and module data should = live in memory unless there=92s a very good reason to be reading it in = real-time. Again, I=92ll 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.=20 =20 Framework data will be dealt with entirely within the Rainbow core =96 = not particular need for fancy developer-friendly DAL stuff there =96 the = core can offer a range of backend options, each of which may or may not support farming, but how it=92s implemented internally is of no interest outside = the ring of core developers. =20 User data is one of our big weaknesses at the moment =96 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=92s a =93one-off=94 exercise with no particular requirement for = code-level friendliness. =20 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=92t even assume that the data is available! =20 To use an analogy, I believe we are discussing the dimensions and composition of bricks when we should still be talking to the architect. =20 Jes1111 =20 PS: I managed to write all of that without once mentioning XML! My psychiatrist will be so pleased! =20 |
From: Cory I. <cis...@ya...> - 2003-08-26 04:10:28
|
Rainbow Devs,=20 Something I have been thinking about that we should consider as we move = forward. DotNetNuke has some good devleopers working on it and it has a = lot of similiarty to Rainbow since they both derived from IBS. Intially = I would like to see if we can pursue implementing both a Rainbow and = Nuke interface in our module implementations so that out of the box our = module devleopers can support both portals. I do not even know if Nuke = modules currently implement any interfaces, but it should not be = difficult to look into. I know a Nuke developer here in town so I can = get some communication into their group if needed. This will especially = help commercial module developers who want to support both portals. = Lets show Nuke that we are interested in working with them by supporting = them with our modules. There may be some Nuke developers not interested = in working with us, but the ones I know myself are not so stubborn. By = having different assemblies for the various functions we may be able to = work with Nuke to benefit both groups. I would like to have some of = their people working with us on user interface and such. If we can = create a good working environment for supporting code that works well = together then perhaps the single portal vision can come true. By using = interfaces for everything I should even be able to create Nuke = implementations of many Rainbow features. I have had many conversations = with developers who are trying to decide which portal to use and work = with. I hate the fact that they must pick one. If we can do anything = to bring Nuke and Rainbow together then I believe that will be a = positive move. It is something that I certainly will consider with the = work I do for Rainbow.=20 Anyone going to the PDC in Los Angeles at the end of October? I would = love to meet up with you there! Cory Isakson |
From: mark m. <mar...@ho...> - 2003-08-30 14:01:48
|
The current security model may present some problems. Rainbow allows finer control of security, although I guess you could just 'default' back to the IBS module behavior. I think its a great idea to have 'module adapters'. Module installation would be another area of concern for module developers. If we could define a standard module interface implementation, and installation process, this would go a long way toward bringing the two platforms together. -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of Cory Isakson Sent: Tuesday, August 26, 2003 7:03 AM To: rai...@li... Subject: [Rainbowportal-devel] Bridgin the Nuke / Rainbow Gap Rainbow Devs, Something I have been thinking about that we should consider as we move forward. DotNetNuke has some good devleopers working on it and it has a lot of similiarty to Rainbow since they both derived from IBS. Intially I would like to see if we can pursue implementing both a Rainbow and Nuke interface in our module implementations so that out of the box our module devleopers can support both portals. I do not even know if Nuke modules currently implement any interfaces, but it should not be difficult to look into. I know a Nuke developer here in town so I can get some communication into their group if needed. This will especially help commercial module developers who want to support both portals. Lets show Nuke that we are interested in working with them by supporting them with our modules. There may be some Nuke developers not interested in working with us, but the ones I know myself are not so stubborn. By having different assemblies for the various functions we may be able to work with Nuke to benefit both groups. I would like to have some of their people working with us on user interface and such. If we can create a good working environment for supporting code that works well together then perhaps the single portal vision can come true. By using interfaces for everything I should even be able to create Nuke implementations of many Rainbow features. I have had many conversations with developers who are trying to decide which portal to use and work with. I hate the fact that they must pick one. If we can do anything to bring Nuke and Rainbow together then I believe that will be a positive move. It is something that I certainly will consider with the work I do for Rainbow. Anyone going to the PDC in Los Angeles at the end of October? I would love to meet up with you there! Cory Isakson |
From: Ed D. <ra...@es...> - 2003-09-02 00:51:13
|
MessageIMO I agree that Nuke has made good progress as a successor platform to IBS but so has Rainbow. I don't think it is so bad that developers can choose which portal they prefer, choice is a great thing. The time spent on creating adapters so that we can leverage development efforts on both platforms is a good idea but perhaps a little early. For now we can share data via xml and the format of that between these and subsequent portal implementations might be an area to focus on with respect to XSDs etc.. To be considering merging two projects so soon might actually put Rainbow at risk. I would hope we would want to spend our precious resource - time - on improving and enhancing the Rainbow project directly. I think this issue could distract us from more important work that we want to carry out. We are in control of Rainbow and can continue to evolve the software; we are not in control of the decision making at Nuke and therefore time is required to liaise concurrently with Nuke in order to keep abreast of design changes with their project. Has anyone from the Nuke project team contacted us with the same idea yet? If so then perhaps we can assign someone to liaise with that person for now? Regards, Ed -----Original Message----- From: rai...@li... [mailto:rai...@li...]On Behalf Of mark mcfarlane Sent: 30 August 2003 15:03 To: rai...@li... Subject: RE: [Rainbowportal-devel] Bridgin the Nuke / Rainbow Gap The current security model may present some problems. Rainbow allows finer control of security, although I guess you could just 'default' back to the IBS module behavior. I think its a great idea to have 'module adapters'. Module installation would be another area of concern for module developers. If we could define a standard module interface implementation, and installation process, this would go a long way toward bringing the two platforms together. -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of Cory Isakson Sent: Tuesday, August 26, 2003 7:03 AM To: rai...@li... Subject: [Rainbowportal-devel] Bridgin the Nuke / Rainbow Gap Rainbow Devs, Something I have been thinking about that we should consider as we move forward. DotNetNuke has some good devleopers working on it and it has a lot of similiarty to Rainbow since they both derived from IBS. Intially I would like to see if we can pursue implementing both a Rainbow and Nuke interface in our module implementations so that out of the box our module devleopers can support both portals. I do not even know if Nuke modules currently implement any interfaces, but it should not be difficult to look into. I know a Nuke developer here in town so I can get some communication into their group if needed. This will especially help commercial module developers who want to support both portals. Lets show Nuke that we are interested in working with them by supporting them with our modules. There may be some Nuke developers not interested in working with us, but the ones I know myself are not so stubborn. By having different assemblies for the various functions we may be able to work with Nuke to benefit both groups. I would like to have some of their people working with us on user interface and such. If we can create a good working environment for supporting code that works well together then perhaps the single portal vision can come true. By using interfaces for everything I should even be able to create Nuke implementations of many Rainbow features. I have had many conversations with developers who are trying to decide which portal to use and work with. I hate the fact that they must pick one. If we can do anything to bring Nuke and Rainbow together then I believe that will be a positive move. It is something that I certainly will consider with the work I do for Rainbow. Anyone going to the PDC in Los Angeles at the end of October? I would love to meet up with you there! Cory Isakson --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.515 / Virus Database: 313 - Release Date: 01/09/2003 |
From: Chad T. <paq...@ho...> - 2003-09-02 15:49:59
|
MessageI have worked on both projects and I agree with Ed. The = direction of Nuke and the direction of Rainbow are very different. Nuke = has no desire to make a platform capable of running on multiple = databases, nor are they pushing in a multi-lingual direction. I think = the scope of Rainbow is one that will produce a very sophisticated = portal, and while Nuke has some good things, it appears to be short = sighted in several areas we consider important. Thanks Chad ----- Original Message -----=20 From: Ed Daniel=20 To: Rainbowportal-Devel=20 Sent: Monday, September 01, 2003 6:51 PM Subject: RE: [Rainbowportal-devel] Bridgin the Nuke / Rainbow Gap IMO I agree that Nuke has made good progress as a successor platform = to IBS but so has Rainbow. I don't think it is so bad that developers = can choose which portal they prefer, choice is a great thing. The time spent on creating adapters so that we can leverage = development efforts on both platforms is a good idea but perhaps a = little early. For now we can share data via xml and the format of that = between these and subsequent portal implementations might be an area to = focus on with respect to XSDs etc.. To be considering merging two projects so soon might actually put = Rainbow at risk. I would hope we would want to spend our precious = resource - time - on improving and enhancing the Rainbow project = directly. I think this issue could distract us from more important work that we = want to carry out. We are in control of Rainbow and can continue to = evolve the software; we are not in control of the decision making at = Nuke and therefore time is required to liaise concurrently with Nuke in = order to keep abreast of design changes with their project. Has anyone from the Nuke project team contacted us with the same idea = yet? If so then perhaps we can assign someone to liaise with that = person for now? Regards, Ed -----Original Message----- From: rai...@li... = [mailto:rai...@li...]On Behalf Of = mark mcfarlane Sent: 30 August 2003 15:03 To: rai...@li... Subject: RE: [Rainbowportal-devel] Bridgin the Nuke / Rainbow Gap The current security model may present some problems. Rainbow = allows finer control of security, although I guess you could just = 'default' back to the IBS module behavior. I think its a great idea to have 'module adapters'. Module installation would be another area of concern for module = developers. If we could define a standard module interface implementation, and = installation process, this would go a long way toward bringing the two = platforms together. -----Original Message----- From: rai...@li... = [mailto:rai...@li...] On Behalf Of = Cory Isakson Sent: Tuesday, August 26, 2003 7:03 AM To: rai...@li... Subject: [Rainbowportal-devel] Bridgin the Nuke / Rainbow Gap Rainbow Devs,=20 Something I have been thinking about that we should consider as we = move forward. DotNetNuke has some good devleopers working on it and it = has a lot of similiarty to Rainbow since they both derived from IBS. = Intially I would like to see if we can pursue implementing both a = Rainbow and Nuke interface in our module implementations so that out of = the box our module devleopers can support both portals. I do not even = know if Nuke modules currently implement any interfaces, but it should = not be difficult to look into. I know a Nuke developer here in town so = I can get some communication into their group if needed. This will = especially help commercial module developers who want to support both = portals. Lets show Nuke that we are interested in working with them by = supporting them with our modules. There may be some Nuke developers not = interested in working with us, but the ones I know myself are not so = stubborn. By having different assemblies for the various functions we = may be able to work with Nuke to benefit both groups. I would like to = have some of their people working with us on user interface and such. = If we can create a good working environment for supporting code that = works well together then perhaps the single portal vision can come true. = By using interfaces for everything I should even be able to create Nuke = implementations of many Rainbow features. I have had many conversations = with developers who are trying to decide which portal to use and work = with. I hate the fact that they must pick one. If we can do anything = to bring Nuke and Rainbow together then I believe that will be a = positive move. It is something that I certainly will consider with the = work I do for Rainbow.=20 Anyone going to the PDC in Los Angeles at the end of October? I = would love to meet up with you there! Cory Isakson |
From: Cory I. <cis...@ya...> - 2003-09-03 22:26:04
|
MessageChad, Please take a look at the DNN site under projects and you will see that = Shawn has been working hard on a a database abstraction and has had = success with using Access. Also, there is a group that has incorporated = esperantus and I understand that will be in the core in the future if = not already. There certainly are reasons to have both projects, but = where we can work together I believe it makes good sense. Cory Isakson ----- Original Message -----=20 From: Chad Thompson=20 To: Ed Daniel ; Rainbowportal-Devel=20 Sent: Tuesday, September 02, 2003 9:48 AM Subject: Re: [Rainbowportal-devel] Bridgin the Nuke / Rainbow Gap I have worked on both projects and I agree with Ed. The direction of = Nuke and the direction of Rainbow are very different. Nuke has no = desire to make a platform capable of running on multiple databases, nor = are they pushing in a multi-lingual direction. I think the scope of = Rainbow is one that will produce a very sophisticated portal, and while = Nuke has some good things, it appears to be short sighted in several = areas we consider important. Thanks Chad |
From: Cory I. <cis...@ya...> - 2003-08-26 04:10:30
|
Manu, I am with you! Breaking Rainbow into smaller more manageable pieces = definitely needs to happen. For the next few months I can only function = at the coder level because of time. In December I finish my college = courses and I can devote a more time to Rainbow. I will be involved = with Rainbow structure. I have many interests in terms of caching as = much as possible and doing it intelligently enough for it to work well = on a web farm. I am looking forward to working more closely with the = portal structure and data team. Cory Isakson ----- Original Message -----=20 From: manu=20 To: rai...@li...=20 Sent: Monday, August 25, 2003 10:10 AM Subject: [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: a.. Structure (Portals / Tabs / Modules*) *from placement point of = view, i.e. the rainbow tree.=20 b.. User / Roles / Groups management=20 c.. Permissions=20 d.. Design and Layout=20 e.. Globalization=20 f.. Modules (not part of this discussion)=20 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". Some goals: a.. Separate a large project into many smaller ones=20 b.. 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).=20 c.. For each project is defined a set of Interfaces. Basing = everything on Interfaces means that actual implementations are easily = replaceable.=20 d.. Initial specifications of a project (i.e. Interfaces) are = approved by this list (to avoid unpredicted or incompatible behaviours). = e.. Part of Interface definition will be clear documentation.=20 f.. Each Interface definition will provide a test suite (NUnit) that = implementation teams will run on any implementation.=20 g.. Each test suite has a reference to the Interface and a = progressive identification of subsequent versions.=20 h.. 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.)=20 i.. An implementation is defined as "compatible" with the = specification if it can run all provided tests without errors. = Compatibility must specify test version.=20 a.. 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.=20 b.. Many interface implementation can be available.=20 c.. Interface implementation can be written by teams other than main = team or independent teams. This will lead to a more distributed = development.=20 d.. Within their own organization, Rainbow developers may use a = standard implementation or provide their own according to their specific = needs.=20 e.. 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).=20 f.. Rainbow will became a more distributed effort (a collection of = projects) rather than a single monolithic code block.=20 g.. When an interface is available accessing data directly is = deprecated.=20 h.. 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 ;-) .=20 COORDINATOR TASKS 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=20 a.. Decide the maximum number of people involved in a specific = project.=20 b.. Decide the procedure for accepting new members and for leaving = the team.=20 c.. Manage new members that want participate and members that want = to leave.=20 d.. Contact on regular basis team members to ensure progress.=20 e.. Know all members involved at any given time and how much they = are involved. Know how many hours per week each developer can assure.=20 f.. Move specific tasks from one developer to another based on = individual available time.=20 g.. Regularly read and reply to project forum. Forward specific = issues to the responsible person(s) if something needs attention.=20 h.. Define which quality goals must be met for a release and verify = that any new release complies with it.=20 i.. Revise documentation.=20 HELPING COORDINATION 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 a.. Coordinate ideas in whitepapers and interface definitions.=20 b.. Scan newsgroups, lists and internet in general to collect new = ideas for later review with other team members.=20 c.. Ensure that all jobs done by programmers comply with initial = goals and requirements.=20 d.. Ensure that a certain number of bugs are fixed before adding new = features.=20 e.. Ensure deadlines are met.=20 f.. Manage support requests if applicable (this can be part of bug = fixing cycle).=20 g.. Revise code.=20 CODER 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). HELPER 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: a.. 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=3D3320#406= 6 - some code and interface are already coded by Geert.=20 b.. 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.=20 Now the questions are: 1.. Do you agree with the goals proposed (generally speaking)?=20 2.. 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?=20 Additional projects are (this is not a comprehensive list, only some = project that I remember at moment. Any other idea is welcome.): a.. 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.)=20 a.. Ecommerce=20 b.. ICATS as proposed by Jackobs (see archive)=20 c.. Design (Layouts, Theme, integration with VS 2004), maybe more = than one project.=20 d.. 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.)=20 e.. Intercommunication between modules: = http://aspalliance.com/bbilbro/DesktopDefault.aspx?tabindex=3D1&tabid=3D7= &ArticleID=3D6=20 f.. Other projects like Scheduler, Monitor, and more to come. these = are only some ideas.=20 Sincerely Manu ------------------------------------ Emmanuele De Andreis Technical Manager DUEMETRI Internet Solutions Provider RAINBOW PORTAL Main portal - http://www.rainbowportal.net Sourceforge CVS - http://sourceforge.net/projects/rainbowportal/ Support Forums - http://www.rainbowportal.net/ASPNetForums Bug Tracker - = http://sourceforge.net/tracker/?group_id=3D66837&atid=3D515929 -----Messaggio originale----- Da: rai...@li... = [mailto:rai...@li...] Per conto di = Jeremy Esland Inviato: venerd=EC 22 agosto 2003 20.26 A: cis...@ya...; '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.=20 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. Jes1111 PS: I managed to write all of that without once mentioning XML! My = psychiatrist will be so pleased! |
From: Ender M. <end...@ya...> - 2003-08-26 14:51:51
|
All agreed, I have one more thing to add. The whole time I have been on this project, I keep seing ideas about the new DAL, new security system, how modules should be structured etc. etc. I am sure I can even find discussions about these from a year ago. The problem is most of these discussions end up with no result. And I hate seeing so many good ideas geting wasted (well to an extent). I propose, apart from having coordinators for DLLs, I think we should also assign ownership to individual sub-projects like DAL, Security, Module Layout. These owners should be responsible with collecting ideas and designing and implementing the whole sub-project. But being responsible does not necessarily mean that he has to do everything by himself. He just makes sure that it gets done. Ender --- manu <ma...@du...> wrote: > 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 > * Permissions > * Design and Layout > * Globalization > * Modules (not part of this discussion) > > The main idea behind this is: Lets move each of these areas into a > separate DLL, implementing a well defined and, if possible, STANDARD > (whatever that means ;-) ) set of interfaces. > > Some goals: > > * 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 ;-) . > > > > COORDINATOR TASKS > > 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. > > HELPING COORDINATION > > 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. > > CODER > > 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). > > HELPER > > 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: > > 1. Do you agree with the goals proposed (generally speaking)? > 2. 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.) > > * Ecommerce > === message truncated === __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com |
From: mark m. <mar...@ho...> - 2003-08-30 13:35:08
|
Manu, great email on what needs to happen after the 1.0 release. I agree with your proposals. Ender's idea to break down the structure group into subgroups make sense, but someone needs to control the architecture. In my experience, regardless of the project size, it is best to have a single person as the chief architect for an entire product/framework. This person isn't the only person who does architecture work, but they are the main contact for any and all changes, and they know the entire architecture inside out. They are responsible for how components fit together (the interface definitions you propose). They understand and promote the design patterns used in the system. The chief architect has the final say in all design issues. Designing by committee is very difficult and doesn't work well in the 10 or so commercial products I have delivered over the past 20 years. Also, although I absolutely agree that module writes should be allowed to do their own design, it would be helpful if we had guidelines and common design principles used in the core modules. At a minimum, I'd like to see the module tutorial updated showing all of the 'best practices' for writing a module. My vision for the next Rainbow: 1) It comes after we have a very stable v1.0 release 2) It does not break the code of all of the existing add-on modules (including non-core ones that our users write), or at least any required code changes are well documented and good instructions for upgrading are provided. 3) We ship with the same set of core modules, and the upgrade process installs updated modules and doesn't loose any data or functionality. Mark McFarlane -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of Ender Malkoc Sent: Tuesday, August 26, 2003 5:51 PM To: rai...@li... Subject: Re: [Rainbowportal-devel] My vision about next Rainbow. All people that want collaborate should read this. RE: to "Ideas about new DAL layer" All agreed, I have one more thing to add. The whole time I have been on this project, I keep seing ideas about the new DAL, new security system, how modules should be structured etc. etc. I am sure I can even find discussions about these from a year ago. The problem is most of these discussions end up with no result. And I hate seeing so many good ideas geting wasted (well to an extent). I propose, apart from having coordinators for DLLs, I think we should also assign ownership to individual sub-projects like DAL, Security, Module Layout. These owners should be responsible with collecting ideas and designing and implementing the whole sub-project. But being responsible does not necessarily mean that he has to do everything by himself. He just makes sure that it gets done. Ender --- manu <ma...@du...> wrote: > 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 > * Permissions > * Design and Layout > * Globalization > * 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". > > Some goals: > > * 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 ;-) . > > > > COORDINATOR TASKS > > 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. > > HELPING COORDINATION > > 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. > > CODER > > 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). > > HELPER > > 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#40 > 66 - 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: > > 1. Do you agree with the goals proposed (generally speaking)? > 2. 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.) > > * Ecommerce > === message truncated === __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0 _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel |
From: Ed D. <ra...@es...> - 2003-09-02 00:59:46
|
Further ideas in relation to this would be leveraging the Kickstarter.NET tool (www.kickstarter.net). All core developers on the Rainbow project have been granted permission to download and acquire a license key to use this tool free of charge and I believe Manu has already been experimenting with it. This tool is a RAD code generator. It can use 'patterns' to build code (fyi: example of patterns http://www.dofactory.com/patterns/Patterns.aspx) I think it would be to our advantage to also look at how we can evolve our own 'Rainbow patterns' to help the coding effort required and maintain commonality when moving to V2. Regards, Ed --- manu <ma...@du...> wrote: > 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 > * Permissions > * Design and Layout > * Globalization > * 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". > > Some goals: > > * 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 ;-) . > > > > COORDINATOR TASKS > > 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. > > HELPING COORDINATION > > 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. > > CODER > > 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). > > HELPER > > 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#40 > 66 - 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: > > 1. Do you agree with the goals proposed (generally speaking)? > 2. 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.) > > * Ecommerce > === message truncated === __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0 _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.512 / Virus Database: 309 - Release Date: 19/08/2003 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.515 / Virus Database: 313 - Release Date: 01/09/2003 |
From: mark m. <mar...@ho...> - 2003-09-02 18:30:25
|
Along the line of patterns, I'd like to see at least one module that is well documented, just above non-trivial in functionality so its not too hard to follow, and follows what we feel are the 'best practices' for building a Rainbow module. This along with a tutorial could go along way helping new developers extend Rainbow (and helping some of us old timer module writers adapt to some of the architecture changes). Any volunteers? I'm sure we could get a group of people together to do code reviews of a short module. I also like the idea of a code generator for cranking out quick modules. Also, I'd love it if someone were to spend a little more time on the 'user defined table' module. It allows end users to build new modules for basic list types. This is an incredibly powerful concept that we haven't explorer yet. The implementation in SharePoint team server was really good and valuable. -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of Ed Daniel Sent: Tuesday, September 02, 2003 4:00 AM To: Rainbowportal-Devel Subject: RE: [Rainbowportal-devel] My vision about next Rainbow. All people that want collaborate should read this. Further ideas in relation to this would be leveraging the Kickstarter.NET tool (www.kickstarter.net). All core developers on the Rainbow project have been granted permission to download and acquire a license key to use this tool free of charge and I believe Manu has already been experimenting with it. This tool is a RAD code generator. It can use 'patterns' to build code (fyi: example of patterns http://www.dofactory.com/patterns/Patterns.aspx) I think it would be to our advantage to also look at how we can evolve our own 'Rainbow patterns' to help the coding effort required and maintain commonality when moving to V2. Regards, Ed --- manu <ma...@du...> wrote: > 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 > * Permissions > * Design and Layout > * Globalization > * 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". > > Some goals: > > * 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 ;-) . > > > > COORDINATOR TASKS > > 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. > > HELPING COORDINATION > > 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. > > CODER > > 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). > > HELPER > > 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#40 > 66 - 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: > > 1. Do you agree with the goals proposed (generally speaking)? > 2. 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.) > > * Ecommerce > === message truncated === __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0 _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.512 / Virus Database: 309 - Release Date: 19/08/2003 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.515 / Virus Database: 313 - Release Date: 01/09/2003 ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel |
From: Cory I. <cis...@ya...> - 2003-09-03 22:26:05
|
Mark, Outstanding ideas here. I have some new developer friends that are getting interested in portals and may end up helping with some of these kind of things. One issue we have talked about that would help Rainbow is if there was good samples and documentation on building modules in VB.NET. Part of DNN's success is the fact that there are so many VB types that are scared by C#. Cory Isakson > Along the line of patterns, I'd like to see at least one module that is > well documented, just above non-trivial in functionality so its not too > hard to follow, and follows what we feel are the 'best practices' for > building a Rainbow module. This along with a tutorial could go along > way helping new developers extend Rainbow (and helping some of us old > timer module writers adapt to some of the architecture changes). > > Any volunteers? I'm sure we could get a group of people together to do > code reviews of a short module. > > I also like the idea of a code generator for cranking out quick > modules. > |
From: yiming <xuy...@se...> - 2003-08-28 16:24:36
|
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. |
From: mark m. <mar...@ho...> - 2003-08-30 11:29:49
|
Yiming, 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: rai...@li... [mailto:rai...@li...] On Behalf Of yiming Sent: Thursday, August 28, 2003 7:24 PM To: rai...@li... 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. |