Fwd: [IMC-Tech] Active 2: Should we focus our evaluation on DESIGN?

Fri Mar 1 13:37:08 CST 2002

>Delivered-To: mediageek-org-listgeek at mediageek.org
>Delivered-To: imc-tech at indymedia.org
>X-Sent: 28 Feb 2002 22:16:15 GMT
>To: webcoders at cat.org.au, imc-tech at indymedia.org
>From: kevsmith at canada.com
>X-Mailer: Web Mail 3.9.3.5
>X-Sent-From: kevsmith at canada.com
>X-Spam-Status: No, hits=-98.0 required=5.0 
>tests=NO_REAL_NAME,SUBJ_ENDS_IN_Q_MARK,SUPERLONG_LINE,USER_IN_WHITELIST 
>version=2.01
>Subject: [IMC-Tech] Active 2: Should we focus our evaluation on DESIGN?
>Date: 28 Feb 2002 14:16:15 -0800
>
>Hi folks:
>
>Been very busy lately, so I haven't even had time to weigh in on this 
>discussion of Active 2.
>
>I think it's a good idea to look at the codebases, and see what each can 
>bring to the current project.  However, I think that at least parts of the 
>outcome of this can be easily predicted, given the following factors:
>
>a) We've got lots of production PHP code sitting around, both in CVS, and 
>in various city hacks.  We're NOT going to want to throw that away.
>
>b) I'm pretty sure that no codebase is going to be structured exactly the 
>way we want. I've listed some design considerations below, and I think 
>that the end result is going to be that we will want to take the best 
>parts of each of our respective codebases (both design concepts and code), 
>and shoehorn them into whatever structure and objects we come up with.
>
>c) People will feel comfortable in different languages, and I have no 
>doubt that we'll continue to see a diversity of approaches, so we should 
>accomodate that.
>
>So, I think that rather than looking at the FEATURES each code base has to 
>offer (since we'll ultimately want to offer all of them anyway), we should 
>instead look at the DESIGN of each codebase, and figure out a design that 
>will give us the modularity we want for the future, but also facilitate 
>taking code from each codebase that currently exists.
>
>We also need to think about the various hacks of the past, and how we can 
>have a design structure that facilitates less-hackish things in the 
>future.  For instance:
>
>cast_class - I could find no easy way to just display the article itself, 
>without the comments.  This was needed for scripts like print.php3, and my 
>newstatic.php3, so I didn't have to put redundant code right in the script.
>
>colours - I wanted to set the foreground colour for the subheadings, but 
>this option wasn't available, so more finely-grained options would be nice 
>(and in the database!  Changing colour schemes is a royal pain -- it's 
>hard to track down all the occurrences!)
>
>passwords - speaking of finely-grained options, having a good set of 
>passwords set up for allowing access to changing of options, editing 
>static pages via the web (on a per-page basis), etc. would be 
>useful.  Certainly, a provision for user authentication should be 
>added.  For those who choose to post anonymously, a password for each 
>article is appropriate, and will hopefully cut down on tech calls.
>
>features.cgi - what modules like this can we predict for the future, and 
>how can they be more easily integrated with the Active database?  What 
>thought do we need to give to a
>database design that is easily extensible and upgradable?
>
>Other design considerations (apologies for repeating others):
>
>1. ALL text should be localizable, and stored in the database, with web 
>access, and a good set of passwords for varying levels of access. Cache 
>pages should be written out when there are changes, and should be 
>understood by all supported languages.
>
>2. The same applies for any option flags that are set.  We should be able 
>to select the modules we want to use via the web, and if there are 
>multiple modules in different languages, to choose the flavour of module 
>we want.
>
>3. I think URLs should be dynamically generated too, so we can handle 
>Apache rewrites as we choose, and also handle the case where there are 
>multiple programming language options for a given module (each with their 
>own feature set, no doubt!)
>
>4. I think the supported languages should be PHP, Perl, and Python (and 
>any other language that starts with P :).  I think the Java should be 
>maintained as a separate codebase, as it will be more difficult to 
>integrate (though others probably have a better idea about that than I).
>
>5. We definitely need modular solutions in the backend.  If we're using a 
>database, I think there's agreement about moving to MySQL, but there's 
>also options like Freenet and NNTP to consider.  Idan's XML-RPC work 
>should definitely be given some consideration with backend design.
>
>6. I would see most of the coding taking place in support libraries, with 
>a consistent set of objects to access (though features may vary, depending 
>on the state of porting at the time).  The front-end scripts could then be 
>very minimal, and IF we documented the objects well, hopefully they would 
>stay that way.
>
>7. Some consideration should also be given to how we could have customized 
>pages (MyIndymedia) in the future, and how caching, etc. could yield the 
>best performance for that.
>
>8. Our design should also facilitate other methods of submission -- FTP, 
>NNTP, e-mail, FreeNet, etc.
>
>9. For server configuration with CVS down the road, perhaps we could have 
>a production set of object libraries, and a sandbox for each person doing 
>development (with only the languages that they would use).  People would 
>then generally use the production code for their city, but if they had 
>changes, they could swap that in for their test (and keep it there until 
>the next production upgrade).  Just one thought for keeping better 
>synchronization between cities.
>
>Anyway, I think if we focus on design right now, and look at the codebases 
>in that respect, that we'll be able to get to porting code much more 
>quickly, and thus get a finished product with a combined feature set, 
>rather than debating the feature-richness of various code bases.
>
>Kevin.
>
>
>__________________________________________________________
>Get your FREE personalized e-mail at http://www.canada.com
>
>_______________________________________________
>imc-tech mailing list
>imc-tech at lists.indymedia.org
>http://lists.indymedia.org/mailman/listinfo/imc-tech