Re: [Proposal] HiveMind Service Framework
Howard M. Lewis Ship wrote: What I would like to do is to hear from Howard himself (or anyone working on the HiveMind project)! I'm particularly interested in how Avalon can leverage some of the technologies in HiveMind, and I'm equally confident in the ability of Avalon to provide value-add to the HimeMind project - and I'm not talking about classic avalon component interfaces - I'm talking about generic container-side facilities. The is a potential for mutual benefit. Isn't that worth exploring? I aggree with Andy's comments below ... you can't incubate HiveMind inside Avalon. My Blob (http://javatapestry.blogspot.com) discusses this as well, with some other insights (partly into my own neuroticism). Just a point of clarification. Avalon is *not* going to incubate anything. HiveMind *will not exist* inside Avalon. This is simply because Avalon is not engaging in multi-container incubation - period. What Avalon is doing - and what is relevant to your initative and Avalon - it the work going on towards the delivery of a set of common container facilities. There is potential for HimeMind to leverage this and for Avalon to leverage content in HiveMind with respect to this viewpoint and only this viewpoint. Avalon is a community - and within that community is an effort to harmonize different directions in component models taking into account the differences across internal development, and external iniatives. HiveMind is another aspect in that picture. This means more potential, leveraged code, skills, knowledge, users, etc. I happen to think that there is potential in getting together and talking about things like leverage, synergy, projects, etc. I've considered HiveMind an experiment, and experiment that concludes when the community is formed and the code is mature. The nature of open source and the ASL is very fluid; the best ideas from HiveMind can be cherry-picked from the mature codebase. What I'm nervous about is bringing HiveMind into Avalon and mucking up other people's code with my vision. Let me make something real clear A HiveMind product will not land in Avalon. Period. Full-stop. Will-not-happen. Get this notion of HiveMind in Avalon of you mind forever. Can HiveMind contribute to what is happening in Avalon - yes. Is this clear to everyone on this list? Avalon is not a resting place for a particular container project. Avalon is not about incubation. HiveMind will not be some subproject in Avalon. I will not happen! Take my word for it. And this has nothing to do with HiveMind content - its simply a question concerning the strategy in Avalon. The stategy is not about multiple containers - its not even about a single container. Its about the contract and the framework for solutions. I hope that helps clarify things a touch. Sorry if I sound like I'm repating myself but I'm kind of anoyed with some of the miss-information that has been floating around here recently! ;-) While Hivemind is a virgin idea that needs community building, and is not ready for Jakarta -- it is surely not ready for Avalon either. I would be against its entry into Jakarta ATM (and I doubt Howard would propose it). However, I think it is ripe for foundry at jakarta commons or some place appropriate for starting a community. Obviously it should be watched for eventual entry as a Jakarta project. Howard is obviously now qualified to sponsor it in the incubator himself (as I've pretty much vowed never to incubate anything ever again, I'd rather focus my efforts outside of Apache than go through that quagmire of bureaucratic procedure again**). Well, the incubator will be a challenge but there will be explicit rules for leaving incubation and I won't tolerate the incubators going beyond their mandate. The mandate is to show an active community working together and to ensure that there are no IP problems in HiveMind or its depdendant libraries. We will ensure that the mandate and exit rules are explicit before we start. Agreed. Those procedures have been develped with the principal of holding the Incubator PMC accountable step by step from the point of view of people aiming to exit incubation. The procedures should help make an exit rapid and successful. Howard - can you do me a favour and kick of a thread actually detailing what we want - and throw into it what you think or don't think should be your relationship with Avalon. Please keep in mind that everything I've seen so far suggests that you have a 12-18 out-of-date picture of what avalon is and what avalon is doing - and I want to clear that up. I suggested you post a message on [EMAIL PROTECTED] as part of the process. I still think that that the right place to discuss this. I have a backlog of avalon-dev mail to catch up on. No problem. Don't hesitate to jump in with questions. As an Avalon principal, I can assure you that Avalon is not a threat to the potential of an
Re: [Proposal] HiveMind Service Framework
I say that Howard Lewis Ship is a skilled coder and community builder and if he wants to give it a try with HiveMind, while the topic bores me personally, I'll give him my support. If he does want to collaborate with the Avalonites (Avaloners?) then he should be encouraged to do so; however, if his approach is different enough to warrant its own show then I encourage him to do that as well. I trust his judgment to that effect. Personally - I'm interested in getting some feedback from Howard on a number of question I've posted to him on this list and remain hopeful that he or other members of the HiveMind team will leverage the pool of opinions and talent over on Avalon - as a mutually interesting exercise (just as members of that same pools are interested in leveraging the content and knowlege from the HiveMind team). As far as I can se the question of collaboration remains completely open - after all - no discussion has taken place todate either here on over on avalon. I think it would be good to at least do some exploration of mutual interests - don't you? I feel a Jon coming on. Your itch not mine -- However, after your private rants to (at?) me I kind of doubt how genuine this much more eloquent email is. In truth, a rather virgin Hivemind would (ironically considering the name) be consumed by Avalon rather than affecting Avalon. You may find emailing me personally to be rather disappointing as I say pretty much the same things though sometimes more succinctly. Personally, I feel your effort is more likely intent to prevent an alternative to Avalon. I prefer to see Hivemind established as a community (as far as I know Howard is the only member of the community ATM) before exploring as you say. I see no reason to deprive Howard of the opportunity to establish Hivemind and build a community. I do however apologize for attributing the email containing the following statement to you. It was actually from Danny Angus, however the sentiment appears to coincide with yours wouldn't you agree? The danger of having an Avalon alternative @jakarta is that it will be seen by people as somehow being Jakarta's favoured solution, rather than as one of two (or more) alternatives promoted by Avalon. If you see what I mean. The truth is that the Avalon brand is nothing to be sought while Jakarta is. Being consumed by Avalon will, of course, make building a community more difficult. While Hivemind is a virgin idea that needs community building, and is not ready for Jakarta -- it is surely not ready for Avalon either. I would be against its entry into Jakarta ATM (and I doubt Howard would propose it). However, I think it is ripe for foundry at jakarta commons or some place appropriate for starting a community. Obviously it should be watched for eventual entry as a Jakarta project. Howard is obviously now qualified to sponsor it in the incubator himself (as I've pretty much vowed never to incubate anything ever again, I'd rather focus my efforts outside of Apache than go through that quagmire of bureaucratic procedure again**). I do not see a reason while my stating this creates the level of personal angst for you that it more obviously did in your private mails to me nor do I see the need for the duplicity of posting a more frank and angry mail to me followed by one also on the list. I really don't have time for two threads and am rather conceptually against the idea. Though I suppose I could combine my replies on-list if you prefer. -Andy ** Although what a certain person did to avoid it was wrong although I can't say anything about it as I don't think it was on the public list although it damn well should have been. Stephen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Andrew C. Oliver http://www.superlinksoftware.com/poi.jsp Custom enhancements and Commercial Implementation for Jakarta POI http://jakarta.apache.org/poi For Java and Excel, Got POI? The views expressed in this email are those of the author and are almost definitely not shared by the Apache Software Foundation, its board or its general membership. In fact they probably most definitively disagree with everything espoused in the above email. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] HiveMind Service Framework
Andrew C. Oliver wrote in haste: I say that Howard Lewis Ship is a skilled coder and community builder and if he wants to give it a try with HiveMind, while the topic bores me personally, I'll give him my support. If he does want to collaborate with the Avalonites (Avaloners?) then he should be encouraged to do so; however, if his approach is different enough to warrant its own show then I encourage him to do that as well. I trust his judgment to that effect. Personally - I'm interested in getting some feedback from Howard on a number of question I've posted to him on this list and remain hopeful that he or other members of the HiveMind team will leverage the pool of opinions and talent over on Avalon - as a mutually interesting exercise (just as members of that same pools are interested in leveraging the content and knowlege from the HiveMind team). As far as I can se the question of collaboration remains completely open - after all - no discussion has taken place todate either here on over on avalon. I think it would be good to at least do some exploration of mutual interests - don't you? I feel a Jon coming on. Your itch not mine -- However, after your private rants to (at?) me I kind of doubt how genuine this much more eloquent email is. LOL Andrew, you stooping at little low even by your standards. ;-) Don't worry, you'll get a chance to express your yourself! But let's not miss the the question I think it would be good to at least do some exploration of mutual interests - don't you?. You claim is that this is my itch - not yours. My claim is that this is a community itch - not something personal. There is a potential benefit here! Isn't this worth exploring? In truth, a rather virgin Hivemind would (ironically considering the name) be consumed by Avalon rather than affecting Avalon. Maybe you may have a disconnected idea of what Avalon is and what it is doing. If you take a look at the archives you will see some posts addressing the HimeMind project both before and after this thread was initiated. What you will see is technical and community issues being raised and discussed. One thing is clear - avalon is not a candidate incubator for HiveMind - avalon is about a single product. Does that imply consumption? Yes - if consumption were appropriate - the majority of opinion over at avalon is that it is not. You may find emailing me personally to be rather disappointing as I say pretty much the same things though sometimes more succinctly. Personally, I feel your effort is more likely intent to prevent an alternative to Avalon. You sinking down low again! You made some assertions implying that Avalon considered itself as an only solution (you opinion). You went on presented a (weak) justification for that position. My personal email to you expressed my personal opinion concerning, you inaccuracy of the assertions, my confusion pertaining to you justification, and my request for an explanation. Instead of attempting to sidetrack the discussion around Andrew and his personal in-tray - lets focus on the HiveMind community and its role/relevance/synergy within the Apache community. I figure that there is value to be gained - but value requires dialogue and interaction. So far there has not been no dialogue nor interaction. That's the issue to address today. I prefer to see Hivemind established as a community (as far as I know Howard is the only member of the community ATM) before exploring as you say. I see no reason to deprive Howard of the opportunity to establish Hivemind and build a community. What I would like to do is to hear from Howard himself (or anyone working on the HiveMind project)! I'm particularly interested in how Avalon can leverage some of the technologies in HiveMind, and I'm equally confident in the ability of Avalon to provide value-add to the HimeMind project - and I'm not talking about classic avalon component interfaces - I'm talking about generic container-side facilities. The is a potential for mutual benefit. Isn't that worth exploring? I do however apologize for attributing the email containing the following statement to you. It was actually from Danny Angus, however the sentiment appears to coincide with yours wouldn't you agree? The danger of having an Avalon alternative @jakarta is that it will be seen by people as somehow being Jakarta's favoured solution, rather than as one of two (or more) alternatives promoted by Avalon. If you see what I mean. No. I personally don't look at Avalon as the end game. Avalon is a community of people who happen to be focussed on this subject area. There is a lot of stuff happening in this domain. Avalon is rapidly evolving and incorporating new ideas and solutions from users such as Dany (and hundreds of others) combined with multiple external projects in the same area. Avalon is a community - and within that community is an effort to harmonize different
Re: [Proposal] HiveMind Service Framework
Andrew C. Oliver wrote: Perhaps you missed that part of my message. No - I didn't miss anything. What you could do is try to add some rationalization around your arguments instead of making negative assertions about a project you are not involved with and are not interested in. The rest of your email is snipped because it is simply diverging from the real question concerning potential. It seems to me your trying to derail that potential. Well, sorry, I'm not going to be derailed. I have genuine interests in what happens here and I would like to hear from Howard about what he wants and what he thinks the potential synergy could play out with mutual benefit. Stephen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Proposal] HiveMind Service Framework
I prefer to see Hivemind established as a community (as far as I know Howard is the only member of the community ATM) before exploring as you say. I see no reason to deprive Howard of the opportunity to establish Hivemind and build a community. That's what is, in fact, surprising to me ... a small community for HiveMind formed pretty much spontaneously. Like Tapestry, the bulk of the code is from me, but some very significant design ideas, naming conventions and techniques have come form the community and/or been voted on by the nascent community. What I would like to do is to hear from Howard himself (or anyone working on the HiveMind project)! I'm particularly interested in how Avalon can leverage some of the technologies in HiveMind, and I'm equally confident in the ability of Avalon to provide value-add to the HimeMind project - and I'm not talking about classic avalon component interfaces - I'm talking about generic container-side facilities. The is a potential for mutual benefit. Isn't that worth exploring? I aggree with Andy's comments below ... you can't incubate HiveMind inside Avalon. My Blob (http://javatapestry.blogspot.com) discusses this as well, with some other insights (partly into my own neuroticism). Avalon is a community - and within that community is an effort to harmonize different directions in component models taking into account the differences across internal development, and external iniatives. HiveMind is another aspect in that picture. This means more potential, leveraged code, skills, knowledge, users, etc. I happen to think that there is potential in getting together and talking about things like leverage, synergy, projects, etc. I've considered HiveMind an experiment, and experiment that concludes when the community is formed and the code is mature. The nature of open source and the ASL is very fluid; the best ideas from HiveMind can be cherry-picked from the mature codebase. What I'm nervous about is bringing HiveMind into Avalon and mucking up other people's code with my vision. While Hivemind is a virgin idea that needs community building, and is not ready for Jakarta -- it is surely not ready for Avalon either. I would be against its entry into Jakarta ATM (and I doubt Howard would propose it). However, I think it is ripe for foundry at jakarta commons or some place appropriate for starting a community. Obviously it should be watched for eventual entry as a Jakarta project. Howard is obviously now qualified to sponsor it in the incubator himself (as I've pretty much vowed never to incubate anything ever again, I'd rather focus my efforts outside of Apache than go through that quagmire of bureaucratic procedure again**). Well, the incubator will be a challenge but there will be explicit rules for leaving incubation and I won't tolerate the incubators going beyond their mandate. The mandate is to show an active community working together and to ensure that there are no IP problems in HiveMind or its depdendant libraries. We will ensure that the mandate and exit rules are explicit before we start. Howard - can you do me a favour and kick of a thread actually detailing what we want - and throw into it what you think or don't think should be your relationship with Avalon. Please keep in mind that everything I've seen so far suggests that you have a 12-18 out-of-date picture of what avalon is and what avalon is doing - and I want to clear that up. I suggested you post a message on [EMAIL PROTECTED] as part of the process. I still think that that the right place to discuss this. I have a backlog of avalon-dev mail to catch up on. As an Avalon principal, I can assure you that Avalon is not a threat to the potential of an independent HiveMind project (irrespective of Andrew's ideas of reality). Start talking with us (here or there) and you may find an ally. Of course, while the HiveMind IP fiasco resolves itself, I have some spare time to catch up. To be honest, one of the things that has been an issue for me is the Avalon documentation; many of my questions aren't resolved by the docs I could find, and I have been short on time for wading into the code. Howard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] HiveMind Service Framework
On 12/1/03 2:02 AM, Stephen McConnell [EMAIL PROTECTED] wrote: End of discussion. Excellent. -- Andrew C. Oliver http://www.superlinksoftware.com/poi.jsp Custom enhancements and Commercial Implementation for Jakarta POI http://jakarta.apache.org/poi For Java and Excel, Got POI? The views expressed in this email are those of the author and are almost definitely not shared by the Apache Software Foundation, its board or its general membership. In fact they probably most definitively disagree with everything espoused in the above email. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] HiveMind Service Framework
On 12/1/03 2:47 AM, Stephen McConnell [EMAIL PROTECTED] wrote: I thought you ended our discussion? Okay I guess not. My point continues to be that I don't think Howard should be forced and that if HiveMind builds a community, it is perfectly welcome here regardless of cooperation with Avalon. Avalon has no stranglehold on frameworks. If you agree with me then why is this so emotional to you? Nevermind, lets end this, you get the last word. ;-) -Andy Andrew C. Oliver wrote: Perhaps you missed that part of my message. No - I didn't miss anything. What you could do is try to add some rationalization around your arguments instead of making negative assertions about a project you are not involved with and are not interested in. The rest of your email is snipped because it is simply diverging from the real question concerning potential. It seems to me your trying to derail that potential. Well, sorry, I'm not going to be derailed. I have genuine interests in what happens here and I would like to hear from Howard about what he wants and what he thinks the potential synergy could play out with mutual benefit. Stephen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Andrew C. Oliver http://www.superlinksoftware.com/poi.jsp Custom enhancements and Commercial Implementation for Jakarta POI http://jakarta.apache.org/poi For Java and Excel, Got POI? The views expressed in this email are those of the author and are almost definitely not shared by the Apache Software Foundation, its board or its general membership. In fact they probably most definitively disagree with everything espoused in the above email. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] HiveMind Service Framework
Andrew C. Oliver wrote: I don't think that Avalon has any right to have a stranglehold on all service frameworks. Andrew: The Avalon community very aware of the the different approaches that exist. If your following the Avalon dev list you would be aware of ongoing discussions concerning different approaches in the container/component space - the benefits and disadvantages, emergent opportunities, brick-walls, etc. I also must say that I hate the come discuss this in 'our' house approach to collaboration. I'm surprised that you feel this way. If you were subscribed to Avalon dev you would have been aware of discussions concerning HiveMind before the subject came up here. Several members were discussing this subject at a technical level that would not make sense on this list. My invitation to Howard (that seems to have offended you for reasons that I don't understand) was based on the interests in getting some thoughts from the Howard and other members of the HiveMind community on aspect relating to collaboration with Avalon. Perhaps we have different ideas on what that means - for me at least is about sharing ideas and talking - its not (as you suggest) a notion of territory to be protected. I hope that Howard or other members of the HiveMind team take up that invitation because there is potential synergy. One size does not fit all and Avalon has shown over the years that this is especially true for it. Interestingly, the activities over on avalon over the past year have been addressing many of the deeper issues implied by you conclusion. What does one size mean? Is size adaptive? How does one deliver the the parametrized solution that best fits the size that is needed? All of these question are being addressed within Avalon today. I also happen to to think that Howard and the HiveMind team could contribute to that and I also think that the more recent work in Avalon could contribute to HimeMind. I say that Howard Lewis Ship is a skilled coder and community builder and if he wants to give it a try with HiveMind, while the topic bores me personally, I'll give him my support. If he does want to collaborate with the Avalonites (Avaloners?) then he should be encouraged to do so; however, if his approach is different enough to warrant its own show then I encourage him to do that as well. I trust his judgment to that effect. Personally - I'm interested in getting some feedback from Howard on a number of question I've posted to him on this list and remain hopeful that he or other members of the HiveMind team will leverage the pool of opinions and talent over on Avalon - as a mutually interesting exercise (just as members of that same pools are interested in leveraging the content and knowlege from the HiveMind team). As far as I can se the question of collaboration remains completely open - after all - no discussion has taken place todate either here on over on avalon. I think it would be good to at least do some exploration of mutual interests - don't you? Stephen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] HiveMind Service Framework / status
Ear is better, mostly itches now. Don't think I blew the drum as I can hear fine. However I now have a cold too. :-( -Andy On 11/26/03 8:03 AM, Howard M. Lewis Ship [EMAIL PROTECTED] wrote: I'm trying to track down that myself. I need to give my friends at WebCT a call, to see where they are with the software grant. Between that, ApacheCon, a bad cold (how's that ear, Andy?) and the 9-to-5 (oh, and painters in my house) I'm falling a little behind. -- 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 -Original Message- From: Tim O'Brien [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 25, 2003 10:29 PM To: Jakarta General List Subject: Re: [Proposal] HiveMind Service Framework +1 - there is room enough. On a related note, what is the current status of HiveMind? the site is still blanked out in Commons. Could someone please update general as to the current situation re: HiveMind? Andrew C. Oliver wrote: I don't think that Avalon has any right to have a stranglehold on all service frameworks. I also must say that I hate the come discuss this in 'our' house approach to collaboration. One size does not fit all and Avalon has shown over the years that this is especially true for it. I say that Howard Lewis Ship is a skilled coder and community builder and if he wants to give it a try with HiveMind, while the topic bores me personally, I'll give him my support. If he does want to collaborate with the Avalonites (Avaloners?) then he should be encouraged to do so; however, if his approach is different enough to warrant its own show then I encourage him to do that as well. I trust his judgment to that effect. We have Struts, Turbine, and Avalon. We have Velocity, JSP, XSLT, etc. We have commons digester and XMLBeans... None are preferred and BTW Avalon isn't even preferred as Tomcat, for instance, doesn't use it. To suggest that there can be only one true service framework is misguided, IMHO. -Andy On 11/18/03 12:49 AM, Stephen McConnell [EMAIL PROTECTED] wrote: Howard M. Lewis Ship wrote: I'm moniroting the avalon dev list. Howard: As mentioned earlier there are some things that would be interesting to discuss over on the avalon dev list. Perhaps you could put forward you thoughts about the potential or lack thereoff on collaboration. I think some good points have already been put on the table for working together and for working apart - but just at the moment these thoughts are only on the table and no real discussion is happening as a result. I think that could change if we were to go beyond mutual monotoring. Cheers, Steve. -- 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 -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Stephen McConnell Sent: Thursday, November 13, 2003 10:10 PM To: [EMAIL PROTECTED] Subject: Re: [Proposal] HiveMind Service Framework [EMAIL PROTECTED] wrote: I've put up a limited copy of the HiveMind documentation on my personal home page: Howard: Are you open to the idea of discussing some mutual areas of interest? There are a number of aspects of the work you are doing that are complimentary with the work on-going in Avalon, and several areas in Avalon which after review your material are complimentary with your own efforts. Can I get you to sign up to the avalon dev list bacause I would very much like to discuss this further together with other members of the Avalon crew. Details for the Avalon dev list are available at the following URL: http://avalon.apache.org/mailing-lists.html I'm looking forward to hearing from you. Cheers, Stephen. --- -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Andrew C. Oliver http://www.superlinksoftware.com/poi.jsp Custom enhancements and Commercial Implementation for Jakarta POI http://jakarta.apache.org/poi For Java and Excel, Got POI? The views
RE: [Proposal] HiveMind Service Framework
I'm moniroting the avalon dev list. -- 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 -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Stephen McConnell Sent: Thursday, November 13, 2003 10:10 PM To: [EMAIL PROTECTED] Subject: Re: [Proposal] HiveMind Service Framework [EMAIL PROTECTED] wrote: I've put up a limited copy of the HiveMind documentation on my personal home page: Howard: Are you open to the idea of discussing some mutual areas of interest? There are a number of aspects of the work you are doing that are complimentary with the work on-going in Avalon, and several areas in Avalon which after review your material are complimentary with your own efforts. Can I get you to sign up to the avalon dev list bacause I would very much like to discuss this further together with other members of the Avalon crew. Details for the Avalon dev list are available at the following URL: http://avalon.apache.org/mailing-lists.html I'm looking forward to hearing from you. Cheers, Stephen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] HiveMind Service Framework
[EMAIL PROTECTED] wrote: I've put up a limited copy of the HiveMind documentation on my personal home page: Howard: Are you open to the idea of discussing some mutual areas of interest? There are a number of aspects of the work you are doing that are complimentary with the work on-going in Avalon, and several areas in Avalon which after review your material are complimentary with your own efforts. Can I get you to sign up to the avalon dev list bacause I would very much like to discuss this further together with other members of the Avalon crew. Details for the Avalon dev list are available at the following URL: http://avalon.apache.org/mailing-lists.html I'm looking forward to hearing from you. Cheers, Stephen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] HiveMind Service Framework
I still ask myself why we can't put HiveMind as its own project under the Jakarta umbrella. We have projects with a much smaller scope as normal jakarta projects and we have and had framework projects such as Cocoon, Avalon or Turbine outside of the commons. IMHO the scope of HiveMind is already to big for the commons which I see as software snacks: Small, easy to swallow and a side order for larger projects. Regards Henning On Tue, 2003-11-11 at 20:23, Martin Cooper wrote: Accepting this proposal as currently written would also involve the acceptance of five new individuals as Apache committers. Based on where the HiveMind repo currently is/was, that implies giving five unknowns (to me, anyway) access to Jakarta Commons as a whole. I'm not so sure I'd be willing to sign up for that. -- Martin Cooper On Tue, 11 Nov 2003, Nayak, Prashant wrote: Proposal for the HiveMind Project (0) Rationale HiveMind is a simple framework for creating pluggable, configurable, reusable services. Simple: HiveMind is a way to create a network of services in terms of Java interfaces and classes; it cherry picks the most useful ideas from Service Oriented Architectures such as J2EE, JMX and SOAP, but removes the aspects that are typically overkill for most applications, such as service remoteability and language neutrality. HiveMind creates a natural network of related services and configuration data, all operating within a single JVM. Pluggable: HiveMind enforces a complete separation of service definition and implementation. This is manifested by a division of services into an interface definition and a service implementation as well as a split between defining a service (as part of a HiveMind module) and providing the implementation of that service (potentially, in a different module). Configurable: HiveMind integrates a service oriented architecture to a sophisticated configuration architecture; the configuration architecture is adapted from the Eclipse plug-in model, wherein modules may define configuration extension points and multiple modules may provide contributions to those extension points. Reusable: HiveMind is a framework and container, but not an application. The HiveMind framework and the services it provides may be easily combined with application-specific services and configurations for use in disparate applications. The API for HiveMind allows thread-safe, easy access to services and configurations with a minimal amount of code. The value-add for HiveMind is not just runtime flexibility: it is overall developer productivity. HiveMind systems will entail less code; key functionality that is frequently an after-thought, such as parsing of XML configuration files, logging of method invocations, and lazy creation of services, is handled by the HiveMind framework in a consistent, robust, and well-documented manner. HiveMind fits into an area that partially overlaps the Apache Avalon project, with significant differences. HiveMind's concept of a distributed configuration is unique among the available service microkernel's (Avalon, Keel, Spring, Picocontainer, etc.). Avalon is firmly rooted in a type-1 inversion of control pattern (whereby services must explicitly, in code, resolve dependencies between each other using a lookup pattern similar to JNDI). HiveMind uses a mix of type-2 and type-3 IoC, whereby the framework (acting as container) creates connections between services by setting properties of the services (type-2) or making use of particular constructors for the services (type-3). HiveMind represents a generous donation of code to the ASF by WebCT (http://www.webct.com). HiveMind originated from internal requirements for a flexible, loosely-coupled configuration management and services framework for WebCT's industry-leading flagship enterprise e-learning product, Vista. Several individuals in WebCT's research and development team in addition to Mr. Howard Lewis Ship contributed to the requirements and concepts behind HiveMind's current set of functionality including Martin Bayly, Diane Bennett, Bill Bilic, Michael Kerr, Prashant Nayak, Bill Richard and Ajay Sharda. HiveMind is already in use as a significant part of Vista. (1) Scope of the package The package shall entail a core framework JAR (containing essential classes and services), a standard library JAR (containing generically useful services), along with ancillary artifacts such as Maven plug-ins and, of course, documentation, all distributed under the Apache Software License. (1.1) Interaction with other packages HiveMind has dependencies on several standard commons packages, including: commons-lang, commons-beanutils, commons-collections and commons-logging. HiveMind makes use of the Javassist bytecode generation library, which is available
Re: [Proposal] HiveMind Service Framework
I still ask myself why we can't put HiveMind as its own project under the Jakarta umbrella. It doesn't seem unreasonable to me, if the criteria are met and the political implications of creating a new sub-project are acceptable. Otherwise a spell in commons will help to cement the community and do no harm. I would like to know if this has been proposed to Avalon, if not why not, if so what has been their reaction. I'm not suggesting that it should be, just that it might be a better fit with their charter. d. *** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limited. This footnote also confirms that this email message has been swept for the presence of computer viruses. ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] HiveMind Service Framework
On Wed, 12 Nov 2003, Henning Schmiedehausen wrote: I still ask myself why we can't put HiveMind as its own project under the Jakarta umbrella. Isn't that what this proposal is proposing? If it isn't, then [EMAIL PROTECTED] is the wrong list to propose it to. We have projects with a much smaller scope as normal jakarta projects and we have and had framework projects such as Cocoon, Avalon or Turbine outside of the commons. IMHO the scope of HiveMind is already to big for the commons which I see as software snacks: Small, easy to swallow and a side order for larger projects. Yes, this proposal is that HiveMind be a top-level Jakarta project; a peer to (say) Log4J and Tapestry. The commons is largely supposed to be for toolboxes; libraries that contain individual utility classes (commons-lang) or frameworks with a very precise, very focused use (commons-logging). Although you could scavenge a lot of useful stuff out of HiveMind, it is intended for use as a cohesive unit. In terms of homes, I can see a number of possible options: 1) Reject HiveMind outright --- and make Howard very sad. In this case, I would reorganize the Tapestry build to accomidate having HiveMind as a sub-project (once the grants from WebCT come through). I feel that is less than ideal; despite the overlap, and evolution of ideas from Tapestry into HiveMind, I'd prefer to keep them seperate, with seperate teams. 2) Keep it in the commons I have no real objection to this personally, but HiveMind doesn't quite fit with the commons charter, for the reasons discussed above (and in the commons charter). 3) Chuck it over to Avalon I've looked to see how we could graft HiveMind into Avalon and vice-versa, but they are really quite different beasts. The type-1 vs. type-2/type-3 split is intrinsic and difficult to reconcile. HiveMind's concept of a module doesn't map so easily into the Avalon space, and HiveMind's free-for-all approach doesn't jive with Avalon's dogmatic security model (including its explicit application construction descriptor). 4) New TLD I think HiveMind is a totally useful swiss-army knife that opens up the doors for a lot of really terrific approaches to solving common development problems. However, it's still a bit light to be a TLD ... something like 6600 NCLOC if memory serves (don't bet on it!). Certainly if boil-the-ocean frameworks like Struts, Tapestry and Turbine aren't TLDs then HiveMind isn't either. 5) New Jakarta Project As stated in the proposal; this is my preference. -- [EMAIL PROTECTED] Creator, Tapestry: Java Web Components http://jakarta.apache.org/tapestry - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] HiveMind Service Framework
Howard wrote: 3) Chuck it over to Avalon I've looked to see how we could graft HiveMind into Avalon and vice-versa, but they are really quite different beasts. The type-1 vs. type-2/type-3 split is intrinsic and difficult to reconcile. HiveMind's concept of a module doesn't map so easily into the Avalon space, and HiveMind's free-for-all approach doesn't jive with Avalon's dogmatic security model (including its explicit application construction descriptor). I didn't mean to suggest that you should try to move avalon architecture towards hivemind or vice versa, but I did wonder if there would be support @avalon for an alternative approach as an avalon sub-project. The danger of having an Avalon alternative @jakarta is that it will be seen by people as somehow being Jakarta's favoured solution, rather than as one of two (or more) alternatives promoted by Avalon. If you see what I mean. Of course you went through this whole debate when we discussed whether we needed Tapestry as an alternative to Struts, as equal members of Jakarta neither approach can be seen to be in any way an endorsed or favourite. The same (IMO) would not be true for service frameworks if Hivemind was a Jakarta project not an Avalon one. Hivemind would be seen by some to be Jakarta's favoured solution. FWIW I'm certainly not going to oppose this, Hivemind seems to be a well thought out proposal, but I don't want Jakarta to be accused of trying to replace Avalon, and I guess that will mean involving Avalon folks in the discussion. Imagine the reaction there would be if I proposed a make utility as a Jakarta sub-project, and perhaps you'll get the thrust of my concern. d. *** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limited. This footnote also confirms that this email message has been swept for the presence of computer viruses. ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] HiveMind Service Framework
FYI: I think someone wanted this to get forwarded to the Avalon 'general' mailing list, but since that doesn't exist, I thought I'd send it to our dev list. For the Avaloners: There's been a bit of discussion lately on [EMAIL PROTECTED] about what to do with Hivemind seeing that it has started to outgrow its current location in commons-sandbox. Some have suggested that it fits better over here in Avalon (as a sub-project) than in Jakarta. In some respects, I agree. I think its a little light to be its own top-level project (hivemind.apache.org) and if you look at the jakarta charters vs avalon charters, Hivemind falls more on the Avalon side of things. Not sure what Howards thoughts are on that. --- Danny Angus [EMAIL PROTECTED] wrote: Howard wrote: 3) Chuck it over to Avalon I've looked to see how we could graft HiveMind into Avalon and vice-versa, but they are really quite different beasts. The type-1 vs. type-2/type-3 split is intrinsic and difficult to reconcile. HiveMind's concept of a module doesn't map so easily into the Avalon space, and HiveMind's free-for-all approach doesn't jive with Avalon's dogmatic security model (including its explicit application construction descriptor). I didn't mean to suggest that you should try to move avalon architecture towards hivemind or vice versa, but I did wonder if there would be support @avalon for an alternative approach as an avalon sub-project. The danger of having an Avalon alternative @jakarta is that it will be seen by people as somehow being Jakarta's favoured solution, rather than as one of two (or more) alternatives promoted by Avalon. If you see what I mean. Of course you went through this whole debate when we discussed whether we needed Tapestry as an alternative to Struts, as equal members of Jakarta neither approach can be seen to be in any way an endorsed or favourite. The same (IMO) would not be true for service frameworks if Hivemind was a Jakarta project not an Avalon one. Hivemind would be seen by some to be Jakarta's favoured solution. FWIW I'm certainly not going to oppose this, Hivemind seems to be a well thought out proposal, but I don't want Jakarta to be accused of trying to replace Avalon, and I guess that will mean involving Avalon folks in the discussion. Imagine the reaction there would be if I proposed a make utility as a Jakarta sub-project, and perhaps you'll get the thrust of my concern. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- jaaron http://jadetower.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Proposal] HiveMind Service Framework
Proposal for the HiveMind Project (0) Rationale HiveMind is a simple framework for creating pluggable, configurable, reusable services. Simple: HiveMind is a way to create a network of services in terms of Java interfaces and classes; it cherry picks the most useful ideas from Service Oriented Architectures such as J2EE, JMX and SOAP, but removes the aspects that are typically overkill for most applications, such as service remoteability and language neutrality. HiveMind creates a natural network of related services and configuration data, all operating within a single JVM. Pluggable: HiveMind enforces a complete separation of service definition and implementation. This is manifested by a division of services into an interface definition and a service implementation as well as a split between defining a service (as part of a HiveMind module) and providing the implementation of that service (potentially, in a different module). Configurable: HiveMind integrates a service oriented architecture to a sophisticated configuration architecture; the configuration architecture is adapted from the Eclipse plug-in model, wherein modules may define configuration extension points and multiple modules may provide contributions to those extension points. Reusable: HiveMind is a framework and container, but not an application. The HiveMind framework and the services it provides may be easily combined with application-specific services and configurations for use in disparate applications. The API for HiveMind allows thread-safe, easy access to services and configurations with a minimal amount of code. The value-add for HiveMind is not just runtime flexibility: it is overall developer productivity. HiveMind systems will entail less code; key functionality that is frequently an after-thought, such as parsing of XML configuration files, logging of method invocations, and lazy creation of services, is handled by the HiveMind framework in a consistent, robust, and well-documented manner. HiveMind fits into an area that partially overlaps the Apache Avalon project, with significant differences. HiveMind's concept of a distributed configuration is unique among the available service microkernel's (Avalon, Keel, Spring, Picocontainer, etc.). Avalon is firmly rooted in a type-1 inversion of control pattern (whereby services must explicitly, in code, resolve dependencies between each other using a lookup pattern similar to JNDI). HiveMind uses a mix of type-2 and type-3 IoC, whereby the framework (acting as container) creates connections between services by setting properties of the services (type-2) or making use of particular constructors for the services (type-3). HiveMind represents a generous donation of code to the ASF by WebCT (http://www.webct.com). HiveMind originated from internal requirements for a flexible, loosely-coupled configuration management and services framework for WebCT's industry-leading flagship enterprise e-learning product, Vista. Several individuals in WebCT's research and development team in addition to Mr. Howard Lewis Ship contributed to the requirements and concepts behind HiveMind's current set of functionality including Martin Bayly, Diane Bennett, Bill Bilic, Michael Kerr, Prashant Nayak, Bill Richard and Ajay Sharda. HiveMind is already in use as a significant part of Vista. (1) Scope of the package The package shall entail a core framework JAR (containing essential classes and services), a standard library JAR (containing generically useful services), along with ancillary artifacts such as Maven plug-ins and, of course, documentation, all distributed under the Apache Software License. (1.1) Interaction with other packages HiveMind has dependencies on several standard commons packages, including: commons-lang, commons-beanutils, commons-collections and commons-logging. HiveMind makes use of the Javassist bytecode generation library, which is available under the MPL (Mozilla public license). (2) Identify the initial source for the package The initial code base has been developed by Howard M. Lewis Ship within the Jakarta Commons incubator. http://jakarta.apache.org/commons/sandbox/hivemind (2.1) Identify the base name for the package org.apache.hivemind Note: the current code base reflects an alternate package name, org.apache.commons.hivemind. Subsequent research has shown that HiveMind is not a suitable candidate for the Jakarta Commons. The existing code base will be migrated to the new package during the transition out of the sandbox. (2.2) Identify the coding conventions for this package The code follows a modified version of Sun's standard coding conventions, with the following stylistic changes: - instance variables are prefixed with an underscore - a newline is inserted before all braces (3) Identify any Jakarta resources to be created (3.1) mailing lists [EMAIL PROTECTED] -- User discussions [EMAIL PROTECTED] -- Developer discussions and CVS update notifications
RE: [Proposal] HiveMind Service Framework
Please turn off your receipt request when posting. ::-Original Message- ::From: Nayak, Prashant [mailto:[EMAIL PROTECTED] ::Sent: Tuesday, November 11, 2003 12:35 PM ::To: Jakarta General List ::Subject: [Proposal] HiveMind Service Framework :: :: :: ::Proposal for the HiveMind Project :: ::(0) Rationale :: ::HiveMind is a simple framework for creating pluggable, configurable, ::reusable services. :: ::Simple: HiveMind is a way to create a network of services in terms of ::Java interfaces and classes; it cherry picks the most useful ideas from ::Service Oriented Architectures such as J2EE, JMX and SOAP, but removes ::the aspects that are typically overkill for most applications, such as ::service remoteability and language neutrality. HiveMind creates a ::natural network of related services and configuration data, all ::operating within a single JVM. :: ::Pluggable: HiveMind enforces a complete separation of service definition ::and implementation. This is manifested by a division of services into an ::interface definition and a service implementation as well as a split ::between defining a service (as part of a HiveMind module) and providing ::the implementation of that service (potentially, in a different module). :: ::Configurable: HiveMind integrates a service oriented architecture to a ::sophisticated configuration architecture; the configuration architecture ::is adapted from the Eclipse plug-in model, wherein modules may define ::configuration extension points and multiple modules may provide ::contributions to those extension points. :: ::Reusable: HiveMind is a framework and container, but not an application. ::The HiveMind framework and the services it provides may be easily ::combined with application-specific services and configurations for use ::in disparate applications. :: ::The API for HiveMind allows thread-safe, easy access to services and ::configurations with a minimal amount of code. The value-add for HiveMind ::is not just runtime flexibility: it is overall developer productivity. ::HiveMind systems will entail less code; key functionality that is ::frequently an after-thought, such as parsing of XML configuration files, ::logging of method invocations, and lazy creation of services, is handled ::by the HiveMind framework in a consistent, robust, and well-documented ::manner. :: ::HiveMind fits into an area that partially overlaps the Apache Avalon ::project, with significant differences. HiveMind's concept of a ::distributed configuration is unique among the available service ::microkernel's (Avalon, Keel, Spring, Picocontainer, etc.). Avalon is ::firmly rooted in a type-1 inversion of control pattern (whereby services ::must explicitly, in code, resolve dependencies between each other using ::a lookup pattern similar to JNDI). HiveMind uses a mix of type-2 and ::type-3 IoC, whereby the framework (acting as container) creates ::connections between services by setting properties of the services ::(type-2) or making use of particular constructors for the services ::(type-3). :: ::HiveMind represents a generous donation of code to the ASF by WebCT ::(http://www.webct.com). HiveMind originated from internal requirements ::for a flexible, loosely-coupled configuration management and services ::framework for WebCT's industry-leading flagship enterprise e-learning ::product, Vista. Several individuals in WebCT's research and development ::team in addition to Mr. Howard Lewis Ship contributed to the ::requirements and concepts behind HiveMind's current set of functionality ::including Martin Bayly, Diane Bennett, Bill Bilic, Michael Kerr, ::Prashant Nayak, Bill Richard and Ajay Sharda. HiveMind is already in use ::as a significant part of Vista. :: ::(1) Scope of the package :: ::The package shall entail a core framework JAR (containing essential ::classes and services), a standard library JAR (containing generically ::useful services), along with ancillary artifacts such as Maven plug-ins ::and, of course, documentation, all distributed under the Apache Software ::License. :: ::(1.1) Interaction with other packages :: ::HiveMind has dependencies on several standard commons packages, ::including: commons-lang, commons-beanutils, commons-collections and ::commons-logging. :: ::HiveMind makes use of the Javassist bytecode generation library, which ::is available under the MPL (Mozilla public license). :: ::(2) Identify the initial source for the package :: ::The initial code base has been developed by Howard M. Lewis Ship within ::the Jakarta Commons incubator. :: ::http://jakarta.apache.org/commons/sandbox/hivemind :: ::(2.1) Identify the base name for the package :: ::org.apache.hivemind :: ::Note: the current code base reflects an alternate package name, ::org.apache.commons.hivemind. Subsequent research has shown that ::HiveMind is not a suitable candidate for the Jakarta Commons. The ::existing code base will be migrated to the new package during the ::transition out
[Proposal] HiveMind Service Framework
Return Receipt Your [Proposal] HiveMind Service Framework document : was Michael Fraenkel/Raleigh/IBM received by: at: 11/11/2003 13:14:05 EST - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] HiveMind Service Framework
Daft question, possibly, but could someone summarise the IP issue that was happening over HiveMind and how it is currently resolved. I've not been following the thread, but I've seen the noise. Is everything squared away and happy? Hen On Tue, 11 Nov 2003, Nayak, Prashant wrote: Proposal for the HiveMind Project (0) Rationale HiveMind is a simple framework for creating pluggable, configurable, reusable services. Simple: HiveMind is a way to create a network of services in terms of Java interfaces and classes; it cherry picks the most useful ideas from Service Oriented Architectures such as J2EE, JMX and SOAP, but removes the aspects that are typically overkill for most applications, such as service remoteability and language neutrality. HiveMind creates a natural network of related services and configuration data, all operating within a single JVM. Pluggable: HiveMind enforces a complete separation of service definition and implementation. This is manifested by a division of services into an interface definition and a service implementation as well as a split between defining a service (as part of a HiveMind module) and providing the implementation of that service (potentially, in a different module). Configurable: HiveMind integrates a service oriented architecture to a sophisticated configuration architecture; the configuration architecture is adapted from the Eclipse plug-in model, wherein modules may define configuration extension points and multiple modules may provide contributions to those extension points. Reusable: HiveMind is a framework and container, but not an application. The HiveMind framework and the services it provides may be easily combined with application-specific services and configurations for use in disparate applications. The API for HiveMind allows thread-safe, easy access to services and configurations with a minimal amount of code. The value-add for HiveMind is not just runtime flexibility: it is overall developer productivity. HiveMind systems will entail less code; key functionality that is frequently an after-thought, such as parsing of XML configuration files, logging of method invocations, and lazy creation of services, is handled by the HiveMind framework in a consistent, robust, and well-documented manner. HiveMind fits into an area that partially overlaps the Apache Avalon project, with significant differences. HiveMind's concept of a distributed configuration is unique among the available service microkernel's (Avalon, Keel, Spring, Picocontainer, etc.). Avalon is firmly rooted in a type-1 inversion of control pattern (whereby services must explicitly, in code, resolve dependencies between each other using a lookup pattern similar to JNDI). HiveMind uses a mix of type-2 and type-3 IoC, whereby the framework (acting as container) creates connections between services by setting properties of the services (type-2) or making use of particular constructors for the services (type-3). HiveMind represents a generous donation of code to the ASF by WebCT (http://www.webct.com). HiveMind originated from internal requirements for a flexible, loosely-coupled configuration management and services framework for WebCT's industry-leading flagship enterprise e-learning product, Vista. Several individuals in WebCT's research and development team in addition to Mr. Howard Lewis Ship contributed to the requirements and concepts behind HiveMind's current set of functionality including Martin Bayly, Diane Bennett, Bill Bilic, Michael Kerr, Prashant Nayak, Bill Richard and Ajay Sharda. HiveMind is already in use as a significant part of Vista. (1) Scope of the package The package shall entail a core framework JAR (containing essential classes and services), a standard library JAR (containing generically useful services), along with ancillary artifacts such as Maven plug-ins and, of course, documentation, all distributed under the Apache Software License. (1.1) Interaction with other packages HiveMind has dependencies on several standard commons packages, including: commons-lang, commons-beanutils, commons-collections and commons-logging. HiveMind makes use of the Javassist bytecode generation library, which is available under the MPL (Mozilla public license). (2) Identify the initial source for the package The initial code base has been developed by Howard M. Lewis Ship within the Jakarta Commons incubator. http://jakarta.apache.org/commons/sandbox/hivemind (2.1) Identify the base name for the package org.apache.hivemind Note: the current code base reflects an alternate package name, org.apache.commons.hivemind. Subsequent research has shown that HiveMind is not a suitable candidate for the Jakarta Commons. The existing code base will be migrated to the new package during the transition out of the sandbox. (2.2) Identify the coding conventions for this package The code follows a
Re: [Proposal] HiveMind Service Framework
So this proposal is dependent on the grant? Any time line on that? [not trying to get in the way, jsut to do the pmc-thing] On Tue, 11 Nov 2003 [EMAIL PROTECTED] wrote: The offending IP has been taken off-line: this includes the HiveMind CVS repository, the temporary downloads directory and (most regrettably) the HiveMind home page. This proposal is half of the resolution to the IP issue. The other (and possibly more important part) is the software grant that is being processed inside WebCT. -- [EMAIL PROTECTED] Creator, Tapestry: Java Web Components http://jakarta.apache.org/tapestry Daft question, possibly, but could someone summarise the IP issue that was happening over HiveMind and how it is currently resolved. I've not been following the thread, but I've seen the noise. Is everything squared away and happy? Hen On Tue, 11 Nov 2003, Nayak, Prashant wrote: Proposal for the HiveMind Project (0) Rationale HiveMind is a simple framework for creating pluggable, configurable, reusable services. Simple: HiveMind is a way to create a network of services in terms of Java interfaces and classes; it cherry picks the most useful ideas from Service Oriented Architectures such as J2EE, JMX and SOAP, but removes the aspects that are typically overkill for most applications, such as service remoteability and language neutrality. HiveMind creates a natural network of related services and configuration data, all operating within a single JVM. Pluggable: HiveMind enforces a complete separation of service definition and implementation. This is manifested by a division of services into an interface definition and a service implementation as well as a split between defining a service (as part of a HiveMind module) and providing the implementation of that service (potentially, in a different module). Configurable: HiveMind integrates a service oriented architecture to a sophisticated configuration architecture; the configuration architecture is adapted from the Eclipse plug-in model, wherein modules may define configuration extension points and multiple modules may provide contributions to those extension points. Reusable: HiveMind is a framework and container, but not an application. The HiveMind framework and the services it provides may be easily combined with application-specific services and configurations for use in disparate applications. The API for HiveMind allows thread-safe, easy access to services and configurations with a minimal amount of code. The value-add for HiveMind is not just runtime flexibility: it is overall developer productivity. HiveMind systems will entail less code; key functionality that is frequently an after-thought, such as parsing of XML configuration files, logging of method invocations, and lazy creation of services, is handled by the HiveMind framework in a consistent, robust, and well-documented manner. HiveMind fits into an area that partially overlaps the Apache Avalon project, with significant differences. HiveMind's concept of a distributed configuration is unique among the available service microkernel's (Avalon, Keel, Spring, Picocontainer, etc.). Avalon is firmly rooted in a type-1 inversion of control pattern (whereby services must explicitly, in code, resolve dependencies between each other using a lookup pattern similar to JNDI). HiveMind uses a mix of type-2 and type-3 IoC, whereby the framework (acting as container) creates connections between services by setting properties of the services (type-2) or making use of particular constructors for the services (type-3). HiveMind represents a generous donation of code to the ASF by WebCT (http://www.webct.com). HiveMind originated from internal requirements for a flexible, loosely-coupled configuration management and services framework for WebCT's industry-leading flagship enterprise e-learning product, Vista. Several individuals in WebCT's research and development team in addition to Mr. Howard Lewis Ship contributed to the requirements and concepts behind HiveMind's current set of functionality including Martin Bayly, Diane Bennett, Bill Bilic, Michael Kerr, Prashant Nayak, Bill Richard and Ajay Sharda. HiveMind is already in use as a significant part of Vista. (1) Scope of the package The package shall entail a core framework JAR (containing essential classes and services), a standard library JAR (containing generically useful services), along with ancillary artifacts such as Maven plug-ins and, of course, documentation, all distributed under the Apache Software License. (1.1) Interaction with other packages HiveMind has dependencies on several standard commons packages, including: commons-lang, commons-beanutils, commons-collections and commons-logging.
Re: [Proposal] HiveMind Service Framework
From talking with Prashant, the grant is in-progress. Given that these discussions tend to ramble on for a couple of weeks, I think the grant will be ready long before any real action is necessitated. -- [EMAIL PROTECTED] Creator, Tapestry: Java Web Components http://jakarta.apache.org/tapestry So this proposal is dependent on the grant? Any time line on that? [not trying to get in the way, jsut to do the pmc-thing] On Tue, 11 Nov 2003 [EMAIL PROTECTED] wrote: The offending IP has been taken off-line: this includes the HiveMind CVS repository, the temporary downloads directory and (most regrettably) the HiveMind home page. This proposal is half of the resolution to the IP issue. The other (and possibly more important part) is the software grant that is being processed inside WebCT. -- [EMAIL PROTECTED] Creator, Tapestry: Java Web Components http://jakarta.apache.org/tapestry Daft question, possibly, but could someone summarise the IP issue that was happening over HiveMind and how it is currently resolved. I've not been following the thread, but I've seen the noise. Is everything squared away and happy? Hen On Tue, 11 Nov 2003, Nayak, Prashant wrote: Proposal for the HiveMind Project (0) Rationale HiveMind is a simple framework for creating pluggable, configurable, reusable services. Simple: HiveMind is a way to create a network of services in terms of Java interfaces and classes; it cherry picks the most useful ideas from Service Oriented Architectures such as J2EE, JMX and SOAP, but removes the aspects that are typically overkill for most applications, such as service remoteability and language neutrality. HiveMind creates a natural network of related services and configuration data, all operating within a single JVM. Pluggable: HiveMind enforces a complete separation of service definition and implementation. This is manifested by a division of services into an interface definition and a service implementation as well as a split between defining a service (as part of a HiveMind module) and providing the implementation of that service (potentially, in a different module). Configurable: HiveMind integrates a service oriented architecture to a sophisticated configuration architecture; the configuration architecture is adapted from the Eclipse plug-in model, wherein modules may define configuration extension points and multiple modules may provide contributions to those extension points. Reusable: HiveMind is a framework and container, but not an application. The HiveMind framework and the services it provides may be easily combined with application-specific services and configurations for use in disparate applications. The API for HiveMind allows thread-safe, easy access to services and configurations with a minimal amount of code. The value-add for HiveMind is not just runtime flexibility: it is overall developer productivity. HiveMind systems will entail less code; key functionality that is frequently an after-thought, such as parsing of XML configuration files, logging of method invocations, and lazy creation of services, is handled by the HiveMind framework in a consistent, robust, and well-documented manner. HiveMind fits into an area that partially overlaps the Apache Avalon project, with significant differences. HiveMind's concept of a distributed configuration is unique among the available service microkernel's (Avalon, Keel, Spring, Picocontainer, etc.). Avalon is firmly rooted in a type-1 inversion of control pattern (whereby services must explicitly, in code, resolve dependencies between each other using a lookup pattern similar to JNDI). HiveMind uses a mix of type-2 and type-3 IoC, whereby the framework (acting as container) creates connections between services by setting properties of the services (type-2) or making use of particular constructors for the services (type-3). HiveMind represents a generous donation of code to the ASF by WebCT (http://www.webct.com). HiveMind originated from internal requirements for a flexible, loosely-coupled configuration management and services framework for WebCT's industry-leading flagship enterprise e-learning product, Vista. Several individuals in WebCT's research and development team in addition to Mr. Howard Lewis Ship contributed to the requirements and concepts behind HiveMind's current set of functionality including Martin Bayly, Diane Bennett, Bill Bilic, Michael Kerr, Prashant Nayak, Bill Richard and Ajay Sharda. HiveMind is already in use as a significant part of Vista. (1) Scope of the package The package shall entail a core framework JAR (containing essential classes and services), a
Re: [Proposal] HiveMind Service Framework
Cool. Could this be added as a note to the proposal? As a dependency or whatever. Hen On Tue, 11 Nov 2003 [EMAIL PROTECTED] wrote: From talking with Prashant, the grant is in-progress. Given that these discussions tend to ramble on for a couple of weeks, I think the grant will be ready long before any real action is necessitated. -- [EMAIL PROTECTED] Creator, Tapestry: Java Web Components http://jakarta.apache.org/tapestry So this proposal is dependent on the grant? Any time line on that? [not trying to get in the way, jsut to do the pmc-thing] On Tue, 11 Nov 2003 [EMAIL PROTECTED] wrote: The offending IP has been taken off-line: this includes the HiveMind CVS repository, the temporary downloads directory and (most regrettably) the HiveMind home page. This proposal is half of the resolution to the IP issue. The other (and possibly more important part) is the software grant that is being processed inside WebCT. -- [EMAIL PROTECTED] Creator, Tapestry: Java Web Components http://jakarta.apache.org/tapestry Daft question, possibly, but could someone summarise the IP issue that was happening over HiveMind and how it is currently resolved. I've not been following the thread, but I've seen the noise. Is everything squared away and happy? Hen On Tue, 11 Nov 2003, Nayak, Prashant wrote: Proposal for the HiveMind Project (0) Rationale HiveMind is a simple framework for creating pluggable, configurable, reusable services. Simple: HiveMind is a way to create a network of services in terms of Java interfaces and classes; it cherry picks the most useful ideas from Service Oriented Architectures such as J2EE, JMX and SOAP, but removes the aspects that are typically overkill for most applications, such as service remoteability and language neutrality. HiveMind creates a natural network of related services and configuration data, all operating within a single JVM. Pluggable: HiveMind enforces a complete separation of service definition and implementation. This is manifested by a division of services into an interface definition and a service implementation as well as a split between defining a service (as part of a HiveMind module) and providing the implementation of that service (potentially, in a different module). Configurable: HiveMind integrates a service oriented architecture to a sophisticated configuration architecture; the configuration architecture is adapted from the Eclipse plug-in model, wherein modules may define configuration extension points and multiple modules may provide contributions to those extension points. Reusable: HiveMind is a framework and container, but not an application. The HiveMind framework and the services it provides may be easily combined with application-specific services and configurations for use in disparate applications. The API for HiveMind allows thread-safe, easy access to services and configurations with a minimal amount of code. The value-add for HiveMind is not just runtime flexibility: it is overall developer productivity. HiveMind systems will entail less code; key functionality that is frequently an after-thought, such as parsing of XML configuration files, logging of method invocations, and lazy creation of services, is handled by the HiveMind framework in a consistent, robust, and well-documented manner. HiveMind fits into an area that partially overlaps the Apache Avalon project, with significant differences. HiveMind's concept of a distributed configuration is unique among the available service microkernel's (Avalon, Keel, Spring, Picocontainer, etc.). Avalon is firmly rooted in a type-1 inversion of control pattern (whereby services must explicitly, in code, resolve dependencies between each other using a lookup pattern similar to JNDI). HiveMind uses a mix of type-2 and type-3 IoC, whereby the framework (acting as container) creates connections between services by setting properties of the services (type-2) or making use of particular constructors for the services (type-3). HiveMind represents a generous donation of code to the ASF by WebCT (http://www.webct.com). HiveMind originated from internal requirements for a flexible, loosely-coupled configuration management and services framework for WebCT's industry-leading flagship enterprise e-learning product, Vista. Several individuals in WebCT's research and development team in addition to Mr. Howard Lewis Ship contributed to the requirements and concepts behind HiveMind's current set of functionality including Martin Bayly, Diane Bennett, Bill Bilic, Michael Kerr, Prashant Nayak,
RE: [Proposal] HiveMind Service Framework
Just wanted to confirm that the software grant agreement is being processed by WebCT and should hopefully be ready soon. Prashant -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 11, 2003 1:46 PM To: Jakarta General List Subject: Re: [Proposal] HiveMind Service Framework From talking with Prashant, the grant is in-progress. Given that these discussions tend to ramble on for a couple of weeks, I think the grant will be ready long before any real action is necessitated. -- [EMAIL PROTECTED] Creator, Tapestry: Java Web Components http://jakarta.apache.org/tapestry So this proposal is dependent on the grant? Any time line on that? [not trying to get in the way, jsut to do the pmc-thing] On Tue, 11 Nov 2003 [EMAIL PROTECTED] wrote: The offending IP has been taken off-line: this includes the HiveMind CVS repository, the temporary downloads directory and (most regrettably) the HiveMind home page. This proposal is half of the resolution to the IP issue. The other (and possibly more important part) is the software grant that is being processed inside WebCT. -- [EMAIL PROTECTED] Creator, Tapestry: Java Web Components http://jakarta.apache.org/tapestry Daft question, possibly, but could someone summarise the IP issue that was happening over HiveMind and how it is currently resolved. I've not been following the thread, but I've seen the noise. Is everything squared away and happy? Hen On Tue, 11 Nov 2003, Nayak, Prashant wrote: Proposal for the HiveMind Project (0) Rationale HiveMind is a simple framework for creating pluggable, configurable, reusable services. Simple: HiveMind is a way to create a network of services in terms of Java interfaces and classes; it cherry picks the most useful ideas from Service Oriented Architectures such as J2EE, JMX and SOAP, but removes the aspects that are typically overkill for most applications, such as service remoteability and language neutrality. HiveMind creates a natural network of related services and configuration data, all operating within a single JVM. Pluggable: HiveMind enforces a complete separation of service definition and implementation. This is manifested by a division of services into an interface definition and a service implementation as well as a split between defining a service (as part of a HiveMind module) and providing the implementation of that service (potentially, in a different module). Configurable: HiveMind integrates a service oriented architecture to a sophisticated configuration architecture; the configuration architecture is adapted from the Eclipse plug-in model, wherein modules may define configuration extension points and multiple modules may provide contributions to those extension points. Reusable: HiveMind is a framework and container, but not an application. The HiveMind framework and the services it provides may be easily combined with application-specific services and configurations for use in disparate applications. The API for HiveMind allows thread-safe, easy access to services and configurations with a minimal amount of code. The value-add for HiveMind is not just runtime flexibility: it is overall developer productivity. HiveMind systems will entail less code; key functionality that is frequently an after-thought, such as parsing of XML configuration files, logging of method invocations, and lazy creation of services, is handled by the HiveMind framework in a consistent, robust, and well-documented manner. HiveMind fits into an area that partially overlaps the Apache Avalon project, with significant differences. HiveMind's concept of a distributed configuration is unique among the available service microkernel's (Avalon, Keel, Spring, Picocontainer, etc.). Avalon is firmly rooted in a type-1 inversion of control pattern (whereby services must explicitly, in code, resolve dependencies between each other using a lookup pattern similar to JNDI). HiveMind uses a mix of type-2 and type-3 IoC, whereby the framework (acting as container) creates connections between services by setting properties of the services (type-2) or making use of particular constructors for the services (type-3). HiveMind represents a generous donation of code to the ASF by WebCT (http://www.webct.com). HiveMind originated from internal requirements for a flexible, loosely-coupled configuration management and services framework for WebCT's industry-leading flagship enterprise e-learning product, Vista. Several individuals in WebCT's research and development team in addition to Mr. Howard Lewis Ship contributed
Re: [Proposal] HiveMind Service Framework
Once rec'd by myself, I will make note of it. Nayak, Prashant wrote: Just wanted to confirm that the software grant agreement is being processed by WebCT and should hopefully be ready soon. Prashant -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 11, 2003 1:46 PM To: Jakarta General List Subject: Re: [Proposal] HiveMind Service Framework From talking with Prashant, the grant is in-progress. Given that these discussions tend to ramble on for a couple of weeks, I think the grant will be ready long before any real action is necessitated. -- [EMAIL PROTECTED] Creator, Tapestry: Java Web=20 Components http://jakarta.apache.org/tapestry =20 So this proposal is dependent on the grant? =20 Any time line on that? =20 [not trying to get in the way, jsut to do the pmc-thing] =20 On Tue, 11 Nov 2003 [EMAIL PROTECTED] wrote: =20 The offending IP has been taken off-line: this includes the HiveMind CVS repository, the temporary downloads directory and (most=20 regrettably) the HiveMind home page. This proposal is half of the resolution to the IP issue. The other=20 (and possibly more important part) is the software grant that is=20 being processed inside WebCT. -- [EMAIL PROTECTED] Creator, Tapestry: Java Web Components http://jakarta.apache.org/tapestry Daft question, possibly, but could someone summarise the IP issue=20 that was happening over HiveMind and how it is currently resolved. I've not been following the thread, but I've seen the noise. Is=20 everything squared away and happy? Hen On Tue, 11 Nov 2003, Nayak, Prashant wrote: Proposal for the HiveMind Project (0) Rationale HiveMind is a simple framework for creating pluggable,=20 configurable, reusable services. Simple: HiveMind is a way to create a network of services in=20 terms of Java interfaces and classes; it cherry picks the most=20 useful ideas from Service Oriented Architectures such as J2EE,=20 JMX and SOAP, but removes the aspects that are typically=20 overkill for most applications, such as service remoteability=20 and language neutrality. HiveMind creates a natural network of=20 related services and configuration data, all operating within a=20 single JVM. Pluggable: HiveMind enforces a complete separation of service=20 definition and implementation. This is manifested by a division=20 of services into an interface definition and a service=20 implementation as well as a split between defining a service (as part of a HiveMind module) and providing the implementation of that service (potentially, in a different=20 module). Configurable: HiveMind integrates a service oriented=20 architecture to a sophisticated configuration architecture; the=20 configuration architecture is adapted from the Eclipse plug-in=20 model, wherein modules may define configuration extension points and multiple modules may provide contributions to those=20 extension points. Reusable: HiveMind is a framework and container, but not an=20 application. The HiveMind framework and the services it provides may be easily combined with application-specific services and=20 configurations for use in disparate applications. The API for HiveMind allows thread-safe, easy access to services and configurations with a minimal amount of code. The value-add=20 for HiveMind is not just runtime flexibility: it is overall=20 developer productivity. HiveMind systems will entail less code; key functionality that=20 is frequently an after-thought, such as parsing of XML=20 configuration files, logging of method invocations, and lazy=20 creation of services, is handled by the HiveMind framework in a=20 consistent, robust, and well-documented manner. HiveMind fits into an area that partially overlaps the Apache=20 Avalon project, with significant differences. HiveMind's concept of a distributed configuration is unique among the available=20 service microkernel's (Avalon, Keel, Spring, Picocontainer,=20 etc.). Avalon is firmly rooted in a type-1 inversion of control=20 pattern (whereby services must explicitly, in code, resolve=20 dependencies between each other using a lookup pattern similar=20 to JNDI). HiveMind uses a mix of type-2 and type-3 IoC, whereby=20 the framework (acting as container) creates connections between=20 services by setting properties of the services (type-2) or making use of particular constructors for the=20 services (type-3). HiveMind represents a generous donation of code to the ASF by=20 WebCT (http://www.webct.com). HiveMind originated from internal=20
Re: [Proposal] HiveMind Service Framework
Accepting this proposal as currently written would also involve the acceptance of five new individuals as Apache committers. Based on where the HiveMind repo currently is/was, that implies giving five unknowns (to me, anyway) access to Jakarta Commons as a whole. I'm not so sure I'd be willing to sign up for that. -- Martin Cooper On Tue, 11 Nov 2003, Nayak, Prashant wrote: Proposal for the HiveMind Project (0) Rationale HiveMind is a simple framework for creating pluggable, configurable, reusable services. Simple: HiveMind is a way to create a network of services in terms of Java interfaces and classes; it cherry picks the most useful ideas from Service Oriented Architectures such as J2EE, JMX and SOAP, but removes the aspects that are typically overkill for most applications, such as service remoteability and language neutrality. HiveMind creates a natural network of related services and configuration data, all operating within a single JVM. Pluggable: HiveMind enforces a complete separation of service definition and implementation. This is manifested by a division of services into an interface definition and a service implementation as well as a split between defining a service (as part of a HiveMind module) and providing the implementation of that service (potentially, in a different module). Configurable: HiveMind integrates a service oriented architecture to a sophisticated configuration architecture; the configuration architecture is adapted from the Eclipse plug-in model, wherein modules may define configuration extension points and multiple modules may provide contributions to those extension points. Reusable: HiveMind is a framework and container, but not an application. The HiveMind framework and the services it provides may be easily combined with application-specific services and configurations for use in disparate applications. The API for HiveMind allows thread-safe, easy access to services and configurations with a minimal amount of code. The value-add for HiveMind is not just runtime flexibility: it is overall developer productivity. HiveMind systems will entail less code; key functionality that is frequently an after-thought, such as parsing of XML configuration files, logging of method invocations, and lazy creation of services, is handled by the HiveMind framework in a consistent, robust, and well-documented manner. HiveMind fits into an area that partially overlaps the Apache Avalon project, with significant differences. HiveMind's concept of a distributed configuration is unique among the available service microkernel's (Avalon, Keel, Spring, Picocontainer, etc.). Avalon is firmly rooted in a type-1 inversion of control pattern (whereby services must explicitly, in code, resolve dependencies between each other using a lookup pattern similar to JNDI). HiveMind uses a mix of type-2 and type-3 IoC, whereby the framework (acting as container) creates connections between services by setting properties of the services (type-2) or making use of particular constructors for the services (type-3). HiveMind represents a generous donation of code to the ASF by WebCT (http://www.webct.com). HiveMind originated from internal requirements for a flexible, loosely-coupled configuration management and services framework for WebCT's industry-leading flagship enterprise e-learning product, Vista. Several individuals in WebCT's research and development team in addition to Mr. Howard Lewis Ship contributed to the requirements and concepts behind HiveMind's current set of functionality including Martin Bayly, Diane Bennett, Bill Bilic, Michael Kerr, Prashant Nayak, Bill Richard and Ajay Sharda. HiveMind is already in use as a significant part of Vista. (1) Scope of the package The package shall entail a core framework JAR (containing essential classes and services), a standard library JAR (containing generically useful services), along with ancillary artifacts such as Maven plug-ins and, of course, documentation, all distributed under the Apache Software License. (1.1) Interaction with other packages HiveMind has dependencies on several standard commons packages, including: commons-lang, commons-beanutils, commons-collections and commons-logging. HiveMind makes use of the Javassist bytecode generation library, which is available under the MPL (Mozilla public license). (2) Identify the initial source for the package The initial code base has been developed by Howard M. Lewis Ship within the Jakarta Commons incubator. http://jakarta.apache.org/commons/sandbox/hivemind (2.1) Identify the base name for the package org.apache.hivemind Note: the current code base reflects an alternate package name, org.apache.commons.hivemind. Subsequent research has shown that HiveMind is not a suitable candidate for the Jakarta Commons. The existing code base will be migrated to the new package during the transition out of
Re: [Proposal] HiveMind Service Framework
Part of the proposal indicates the jakarta-commons is not the right home for HiveMind, as it does not fit in with the charter of the commons (too many dependencies, etc.). -- [EMAIL PROTECTED] Creator, Tapestry: Java Web Components http://jakarta.apache.org/tapestry Accepting this proposal as currently written would also involve the acceptance of five new individuals as Apache committers. Based on where the HiveMind repo currently is/was, that implies giving five unknowns (to me, anyway) access to Jakarta Commons as a whole. I'm not so sure I'd be willing to sign up for that. -- Martin Cooper On Tue, 11 Nov 2003, Nayak, Prashant wrote: Proposal for the HiveMind Project (0) Rationale HiveMind is a simple framework for creating pluggable, configurable, reusable services. Simple: HiveMind is a way to create a network of services in terms of Java interfaces and classes; it cherry picks the most useful ideas from Service Oriented Architectures such as J2EE, JMX and SOAP, but removes the aspects that are typically overkill for most applications, such as service remoteability and language neutrality. HiveMind creates a natural network of related services and configuration data, all operating within a single JVM. Pluggable: HiveMind enforces a complete separation of service definition and implementation. This is manifested by a division of services into an interface definition and a service implementation as well as a split between defining a service (as part of a HiveMind module) and providing the implementation of that service (potentially, in a different module). Configurable: HiveMind integrates a service oriented architecture to a sophisticated configuration architecture; the configuration architecture is adapted from the Eclipse plug-in model, wherein modules may define configuration extension points and multiple modules may provide contributions to those extension points. Reusable: HiveMind is a framework and container, but not an application. The HiveMind framework and the services it provides may be easily combined with application-specific services and configurations for use in disparate applications. The API for HiveMind allows thread-safe, easy access to services and configurations with a minimal amount of code. The value-add for HiveMind is not just runtime flexibility: it is overall developer productivity. HiveMind systems will entail less code; key functionality that is frequently an after-thought, such as parsing of XML configuration files, logging of method invocations, and lazy creation of services, is handled by the HiveMind framework in a consistent, robust, and well-documented manner. HiveMind fits into an area that partially overlaps the Apache Avalon project, with significant differences. HiveMind's concept of a distributed configuration is unique among the available service microkernel's (Avalon, Keel, Spring, Picocontainer, etc.). Avalon is firmly rooted in a type-1 inversion of control pattern (whereby services must explicitly, in code, resolve dependencies between each other using a lookup pattern similar to JNDI). HiveMind uses a mix of type-2 and type-3 IoC, whereby the framework (acting as container) creates connections between services by setting properties of the services (type-2) or making use of particular constructors for the services (type-3). HiveMind represents a generous donation of code to the ASF by WebCT (http://www.webct.com). HiveMind originated from internal requirements for a flexible, loosely-coupled configuration management and services framework for WebCT's industry-leading flagship enterprise e-learning product, Vista. Several individuals in WebCT's research and development team in addition to Mr. Howard Lewis Ship contributed to the requirements and concepts behind HiveMind's current set of functionality including Martin Bayly, Diane Bennett, Bill Bilic, Michael Kerr, Prashant Nayak, Bill Richard and Ajay Sharda. HiveMind is already in use as a significant part of Vista. (1) Scope of the package The package shall entail a core framework JAR (containing essential classes and services), a standard library JAR (containing generically useful services), along with ancillary artifacts such as Maven plug-ins and, of course, documentation, all distributed under the Apache Software License. (1.1) Interaction with other packages HiveMind has dependencies on several standard commons packages, including: commons-lang, commons-beanutils, commons-collections and commons-logging. HiveMind makes use of the Javassist bytecode generation library, which is available under the MPL (Mozilla public license). (2) Identify the initial source for the package The initial code base has been developed by Howard M. Lewis Ship within the Jakarta Commons incubator.
Re: [Proposal] HiveMind Service Framework
Quoting: Note: the current code base reflects an alternate package name, org.apache.commons.hivemind. Subsequent research has shown that HiveMind is not a suitable candidate for the Jakarta Commons. The existing code base will be migrated to the new package during the transition out of the sandbox. Although Commons-Sandbox access is open to all of Jakarta [or even Apache], I think we can be pretty limited on the Commons access as Hivemind is proposing being a new Jakarta sub-project. Hen On Tue, 11 Nov 2003, Martin Cooper wrote: Accepting this proposal as currently written would also involve the acceptance of five new individuals as Apache committers. Based on where the HiveMind repo currently is/was, that implies giving five unknowns (to me, anyway) access to Jakarta Commons as a whole. I'm not so sure I'd be willing to sign up for that. -- Martin Cooper On Tue, 11 Nov 2003, Nayak, Prashant wrote: Proposal for the HiveMind Project (0) Rationale HiveMind is a simple framework for creating pluggable, configurable, reusable services. Simple: HiveMind is a way to create a network of services in terms of Java interfaces and classes; it cherry picks the most useful ideas from Service Oriented Architectures such as J2EE, JMX and SOAP, but removes the aspects that are typically overkill for most applications, such as service remoteability and language neutrality. HiveMind creates a natural network of related services and configuration data, all operating within a single JVM. Pluggable: HiveMind enforces a complete separation of service definition and implementation. This is manifested by a division of services into an interface definition and a service implementation as well as a split between defining a service (as part of a HiveMind module) and providing the implementation of that service (potentially, in a different module). Configurable: HiveMind integrates a service oriented architecture to a sophisticated configuration architecture; the configuration architecture is adapted from the Eclipse plug-in model, wherein modules may define configuration extension points and multiple modules may provide contributions to those extension points. Reusable: HiveMind is a framework and container, but not an application. The HiveMind framework and the services it provides may be easily combined with application-specific services and configurations for use in disparate applications. The API for HiveMind allows thread-safe, easy access to services and configurations with a minimal amount of code. The value-add for HiveMind is not just runtime flexibility: it is overall developer productivity. HiveMind systems will entail less code; key functionality that is frequently an after-thought, such as parsing of XML configuration files, logging of method invocations, and lazy creation of services, is handled by the HiveMind framework in a consistent, robust, and well-documented manner. HiveMind fits into an area that partially overlaps the Apache Avalon project, with significant differences. HiveMind's concept of a distributed configuration is unique among the available service microkernel's (Avalon, Keel, Spring, Picocontainer, etc.). Avalon is firmly rooted in a type-1 inversion of control pattern (whereby services must explicitly, in code, resolve dependencies between each other using a lookup pattern similar to JNDI). HiveMind uses a mix of type-2 and type-3 IoC, whereby the framework (acting as container) creates connections between services by setting properties of the services (type-2) or making use of particular constructors for the services (type-3). HiveMind represents a generous donation of code to the ASF by WebCT (http://www.webct.com). HiveMind originated from internal requirements for a flexible, loosely-coupled configuration management and services framework for WebCT's industry-leading flagship enterprise e-learning product, Vista. Several individuals in WebCT's research and development team in addition to Mr. Howard Lewis Ship contributed to the requirements and concepts behind HiveMind's current set of functionality including Martin Bayly, Diane Bennett, Bill Bilic, Michael Kerr, Prashant Nayak, Bill Richard and Ajay Sharda. HiveMind is already in use as a significant part of Vista. (1) Scope of the package The package shall entail a core framework JAR (containing essential classes and services), a standard library JAR (containing generically useful services), along with ancillary artifacts such as Maven plug-ins and, of course, documentation, all distributed under the Apache Software License. (1.1) Interaction with other packages HiveMind has dependencies on several standard commons packages, including: commons-lang, commons-beanutils, commons-collections and commons-logging. HiveMind makes use of the Javassist bytecode generation
[Proposal] HiveMind Service Framework
Return Receipt Your [Proposal] HiveMind Service Framework document : was Christopher C Mitchell/Raleigh/IBM received by: at: 11/11/2003 15:09:06 EST - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] HiveMind Service Framework
Quoting [EMAIL PROTECTED]: Part of the proposal indicates the jakarta-commons is not the right home for HiveMind, as it does not fit in with the charter of the commons (too many dependencies, etc.). Even if it were proposed that Hivemind stay in jakarta-commons, I do not share Martin's concern. There have been several cases where a number of new-to-Jakarta committers have joined, and (because of the technical limitations of our permissions infrastructure) have been granted jakarta-commons karma to work on the package they are interested in. In practice, this has not caused any problems. If we are still concerned that it might, we've got a jakarta-commons infrastructure issue to deal with, not a concern about any particular package and its associated committers. -- [EMAIL PROTECTED] Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
