Q1: Migration or clean slate? I'm not a c# expert, so I may be being na´ve in thinking that this is a direct migration from v1. I believe there is already enough separation in the Rainbow code to allow parts to be replaced in a progressive fashion. For example, I don't think it would be difficult to substitute the PortalSettings area or the Layout/Themes area without disturbing the rest of the code too much. I think the most difficult transplant will be the "Data Layer", but the saviour here may be the fact that a new central data/caching facility should be able to co-exist with modules still using their own xxxDB.cs - until "new" versions of the modules can be written.
Q2: How to pass data? Again, forgive me if this is a na´ve answer, but I'd like to see, on the one hand, a number of choices and, on the other hand, a number of specific exclusions. The important aspect is obviously to isolate the use of data from its storage: as such, mechanisms like SQLDataReaders should be specifically excluded, whereas DataSets and XML-based formats (e.g. node lists, XmlDocuments and XmlReaders) should be included, as well as perverse persistence techniques like serialize/deserialize. The broad answer to the question is therefore “objects (from a finite list of possible types)”. Referring again to my desire to see settings data and content data separated, the settings area may be more restrictive in the format(s) it accepts, whereas we should give module-makers the widest possible choices. In an ideal world, a Module should be able to specify its "data schema" as part of it's configuration at installation time; thereafter the data layer will "know" how to send/receive data and actions to/from instances of that module. In my simplistic view, this would be implemented using some kind of "event delegates" system. At the module level, the code should be able to "converse" with the data layer in language something like: "Here's a row – please add it to my datastore” (where the underlined items are things that are “explained” in the configuration settings for that module). And, as if I wasn’t asking enough already, I’d love to see the entire process “transactional”, i.e. with commit/rollback, with a Boolean “success” flag returned in all cases. Perhaps the data layer will also need to be “language aware”, i.e. query criteria such as language (and workflow version?) should have special meaning to the data layer (as a way of removing potential complexity from the module code).
From: email@example.com [mailto:firstname.lastname@example.org] On Behalf Of John M
Sent: 28 March 2003 15:12
Subject: Re: [Rainbowportal-devel] Rainbow v2 Architecture Proposal
Just had a look at the proposed architecture and I think it looks pretty
good. I especially like the way things have been broken up so that the
functionality can be easily seperated.
Will this be a migration of the V1 codebase or a clean slate approach and
just one quick question about how the data will be passed.....DataSet?
This is a question to everyone really to see what your thoughts on how to
move forward are.
>From: "Jeremy Esland" <email@example.com>
>Subject: [Rainbowportal-devel] Rainbow v2 Architecture Proposal
>Date: Fri, 28 Mar 2003 15:01:41 -0000
>Following a long chat with Manu about v2 architecture, I threw this
>diagram together to capture my “vision” of how it could look. Forgive my
>na´ve approach – I’m more comfortable drawing buildings than carving
>Circulate any comments you may have back to the list.
>The attachment is a Visio diagram – if anyone does not have Visio then
>please email me for a rendered version.
><< Rainbowv2ConceptualArchitectureProposal1.vsd >>
It's fast, it's easy and it's free. Get MSN Messenger today!
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
Rainbowportal-devel mailing list