> -----Original Message----- > From: Henri Yandell [mailto:[EMAIL PROTECTED] > Sent: Friday, September 12, 2003 7:29 PM > To: Jakarta Commons Developers List > Subject: RE: [HiveMind] Roll call, please! > > > > > On Fri, 12 Sep 2003, Tim OBrien wrote: > > > What about moving HiveMind out of the Jakarta Commons? I > know this is > > a controversial suggestion, but here me out a little. > > There are two roles in Commons. One is incubation in > Commons-Sandbox, the other is Commons projects that are being > used in various Jakarta [Apache] projects. > > Hivemind is definitely using Commons for incubation I think. > Looking at Howard's email, it even sounds like incubation, > with the Hivemind community not being the Commons community. >
So ... you think I should only request other Jakarta Commons committers to join the HiveMind project? I think that's too limiting. > Nah. It's for the hivemind community and to a lesser extent > the Commons community [and the PMC]. This is where the big > issue comes in. Until Hivemind has community, or at least a > driving Jakarta project, it's unlikely to become a Jakarta > project or Commons proper. HiveMind "spawned" out of Tapestry, in that I took some of the cleverer configuration ideas inside Tapestry and improved them to form HiveMind. My goal is to bring HiveMind to a 1.0 and refactor Tapestry 3.1 to use it heavily. In fact, that's one of the ways I've been guiding the development path, pre-visualizing what Tapestry needs out of it in terms of being able to override existing services and so forth. > > [Continuing in Howard's email] > > > -----Original Message----- > > From: Howard M. Lewis Ship [mailto:[EMAIL PROTECTED] > > Sent: Friday, September 12, 2003 5:03 PM > > To: Jakarta Commons Developers List; 'David Solis'; Harish > > Krishnaswamy; Essl Christian; Johan Lindquist; Andy > Barnett; Bill Lear > > Subject: [HiveMind] Roll call, please! > > > > As I've posted on the the blog, I'm gearing up to form an initial > > HiveMind community. > > > > If you are interested in joining, please drop me an e-mail. > > Why not the list? Fair enough, the list is the right place to post and most parties have posted there. I was concerned that some of the external parties may not be subscribed to the commons-dev list. > > > Once we form up, we should be able to get everyone commit rights to > > the hivemind CVS repository. > > Really? Without any patches/code? Unless they're already > Jakarta (Apache?) committers, commit rights won't be > immediately handed out [I reckon]. That's the point of incubation, isn't it? This is Incubator all over again ... either we're limited to interested already-Jakarta committers (such as Harish and Dave, from Tapestry) or we are in a catch-22 where we can't build a community here. How is any project in the sandbox supposed to get out of it? To me, it's much more presumptious for me to say "I'm Mr. Tapestry, so promote my pet project" than it is to form a real community around the code. By your reckonin' the only approach available is to get a critical mass of existing commons committers involved ... and frankly, HiveMind is a little cramped for that, I think (6K loc, about 125 classes, plus tests). > > > Responsibilities will probably be pretty light; voting on a > trickle of > > issues. Most votes concern addining additional team > members, or votes > > about releases. The fun is not the voting, but the > > discussing of features and design issues. > > People are really worried about the responsibilities? It's > probably true, but I hadn't thought it was needed as a > selling point. It's taken a while, but I've realised the > responsibility is what you step forward and accept and what > the community will allow you to take. I'm projecting on them, perhaps; I'm always concerned about not taking on responsibilities they can't handle. I wanted to inform people about what they could expect because I was inviting outside-of-Apache people who might be intimidated about joining. > > > Step two is to move HiveMind to Jakarta commons proper and set up > > dedicated mailing lists. I'm researching exactly what the rules and > > procedures for this are. > > You can ask for a dedicated list as a Commons project, but > unless you've actually got the content happening I suspect > you'll get quite a few -1's. We don't want httpclient to be a > separate list, it's just too damn noisy. I can live with that; I've got filters. > > > I feel the base framework is pretty much ready to head > towards a 1.0 > > release; initial work will be documentation and (even better) unit > > tests, plus creating additional modules as outlined on my blog. > > Of course, the whole point is we discuss, as a group, what > should get done! > > I applaud the honest of admitting that is currently a > benevolent-dictator driven project. Poor PR though I suspect. :) It's worked for me in the past; I believe that you develop an idea as a focused group to the point where it has some life. HiveMind is at that point, the code and design is feeding on itself quite nicely. That's a reflection of a single view and focus that wouldn't, I think, be possible out of the ether. In fact, the design has changed considerably from where I started with it based on feedback from within WebCT and from several of the people I've extended an invitation to. I think, with the recent spat of documentation I've produced, that there's enough there to support a unified shared vision that can span more than one developer. Perhaps if this had started with a group of 2 - 5 developers meeting in a room, we could have gotten here in a couple of weeks .. instead I've been hacking on HiveMind for a few months, part time. The point is, my insticts say HiveMind can flourish with more input, now. > > > If you haven't worked on an open source project before ... > come on in! > > The water's fine! All it takes is a desire to do some work, > some skill > > at programming, and the right attitude. It's very > > rewarding. > > +1. > > Other questions: > > So how is Hivemind different to Avalon? It seems like it must > clash with the Avalon kernel or something. Not that I grokk > either project. > I'm going to be answering that question quite a bit. Short form: HiveMind combines a powerful services model with a sophisticated, distributed configuration mechanism based on XML. It allows complex, service-oriented architectures to be assembled with minimal code and simple XML descriptors. Long form: At the heart of things, I'm a bit more of an integrator than an innovator. HiveMind is an integration of several different technologies (or ideas extracted from technologies). The major vision is the distributed configuration possible using the Eclipse plugin architecture; an application as an emergent behavior manifesting itself from a large number of extensions and extension points. HiveMind runs with this idea and adds several other concepts: a very strong interface-based services model (similar to some aspects of Avalon) and integrated XML-to-object conversion (similar to Digester). The overall goal is to build better, more robust systems by elminiating code. HiveMind does all the XML parsing ... with line-precise exception reporting adapted from Tapestry. Extension points, as in Eclipse, are slots into which XML contributions are made; like Eclipse, the extension points define a kind of schema for what may be contributed. Beyond this, the schema used in HiveMind includes Digester-like processing rules to convert those contributions into Java objects ready for consumption by the services. Services. HiveMind's service model is somewhat similar to Avalon's, but is not as "secure". It does much of the IoC thing ... for example, it's a snap to connect up two services. HiveMind will set a property of one service as a reference to another service. HiveMind doesn't have the same explicit, external assembly descriptor that Avalon uses; that's why it's not as secure. HiveMind adds in an interceptor concept adapted from JBoss and elsewhere. HiveMind uses a bit of runtime bytecode generation; for example, interceptor objects are fabricated at runtime. HiveMind uses the Javassist framework for this. Because services in HiveMind are always represented as Java interfaces, other tricks are possible. For example, most services are initially manifested as a proxy (another runtime fabricated class). The actual service is only created as needed. So there's definiately some overlap with Avalon. If I didn't have my day job, and the remaining work on "Tapestry in Action", I'd love to survey all the current microkernels, including Avalon, Spring, Pico and so forth. HiveMind is largely built for the needs of my day job, I was just able to sneak it out as open-source as well. The distributed configuration thing is key; the current design of Vista uses a set of unwieldy centralized XML configuration files that are now being gradually broken up into HiveMind modules and extension points. -- Howard M. Lewis Ship Creator, Tapestry: Java Web Components http://jakarta.apache.org/tapestry http://jakarta.apache.org/commons/sandbox/hivemind/ http://javatapestry.blogspot.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
