Hi all, I've enjoyed learning about community building here at Apachecon -- we've had some good conversations we really ought to recap here on the list.
One of the things I picked up from Aaron Farr's talk on community building is how Lokahi needs to have a clear roadmap for what we're trying to accomplish in this podling -- so potential users/contributors can understand what we're about, where we're going, and how they can get involved. I am a Lokahi user, and can contribute documentation, website content and testing, but I'm not involved in the actual code development. I'd like to write content for the website, but I can't do that until we've had the discussions on where we want to go. The below is NOT a list of what the Lokahi community has *agreed* to work on -- it's my informal notes on ideas that came out of happyhours/brainstorming. Ideas: (no particular order) Idea I: change the backend to use JCR/Jackrabbit (see Steve Toback's initial message in this thread) Benefits: - database-agnostic -- Oracle no longer required, increases the "market" of potential users - object versioning (eventually be able to provide an "undo my latest change" feature, and an archive of what a given httpsd.conf file contained at a point in time) - run the whole Lokahi application + repository in a JVM (as opposed to having to install/manage oracle) - easier for interested people to set up / try out --- lowers the barrier to contribution I completely agree that a JCR backend would make Lokahi even more valuable than it is now, and that JCR may have the added benefit of reducing the community-building difficulties we're facing. From in-person discussions here at Apachecon, the JCR work sounds like it's the first priority. Idea J: develop a scripting interface (suggested by Noel Bergman) to get around GUI limitations (rationale: why develop a GUI for tasks that people don't frequently perform? -- just script against the repository/database in a way that also records the audit trail of who-made-what-changes-and-when) Idea K: manage www.apache.org infrastructure with Lokahi (eat own dog food -- don't remember whose idea this was.. Steve's or Noel's?) Benefits: - more visibility, more credibility for Lokahi if it manages *.apache.org Challenges: - need to keep Lokahi continually up-to-date with latest Apache & mod_jk releases -- (would these take priority over the JCR project?) Idea L: patch for latest version of mod_jk Idea M: investigate using Lokahi to help manage Felix/OSGi configurations on mobile devices My question is: which of these ideas should the community tackle first? Are we agreed that it's going to be JCR for sure? Ruth
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Toback Sent: Wednesday, April 25, 2007 5:06 PM To: [email protected] Subject: Lokahi - Status Hey guys Sorry I have had not a lot of time to commit to this project lately. I wanted to outline some of the thoughts I have had about the project. To start a direction sort of conversation. First to outline some of the problems with the application: Install is complicated. (sql scripts are nasty, in my opinion), but it currently works. The ant build script could be improved upon, and the app itself could be improved. Database support is limited. We support Oracle (and most of mysql is the mysql branch) The support of apache/tomcat for configs is limited. more specifically if you use mod_jk, there's a few things that are hard-coded that really shouldn't be. Same goes for tomcat server.xml files. (Velocity templating of config files?) There's been small but infrequent conversations about adding in modular support for other application servers. There is no automated test system. Basically, I think a lot of the focus should be on giving this podling a fighting chance to survive the incubator. I had talked at the last Apachecon about porting the code to use a jsr 170 back-end, ie jackrabbit. This would allow 2 major features - more database support, and a transactional rollback system for configuration changed. Both which are not currently included. This is no small undertaking however. And I'd like to start a discussion around that. This would also work to solve a little bit of the first issue I mentioned - some of the complexity in setting up the app is in fact the database setup itself. When the app was originally designed - the concept was to have two types of modules. One for the application servers, one for 'connector - type' modules. That is something that is roughly followed currently. And could be improved upon. Steve
