JSF (or any framework that supports serverside component/event-based pages and which is pluggable enough) is not incompatible with an action-based controller like Struts. To use them together, you let your JSF pages handle intra-page interactions (possibly spanning multiple requests) and then raise actions on the controller to navigate to other pages (and to run app-level code that your pages shouldn't know about). It fits nicely, and in a lot of ways it's like using JSP as your view tier... only with much more capable pages.
Rich Dakota Jack wrote: >Bolting JSF onto Struts makes no sense. They are simply incompatible. > If you want to do something with the merits of both, you still have >to choose which way you want to go. You cannot go both ways, unless >you are doing it just to fish people in. > >On 10/10/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > > >>Just a few opinions from the peanut gallery... >> >>The era of the "classic" webapp is dead. Any new framework that doesn't >>make it easy (well, EASIER anyway) to develop robust RIAs is dead on >>arrival as far as I am concerned. >> >>Further, I do not believe that the action-centric and component-centric >>models need be exclusive of each other and in fact I believe that is the >>natural evolution of things. I don't think this necessarily implies an >>approach like bolting JSF onto Struts for example, but then again maybe >>that is the most natural path. The real point though is the merging of >>the two approaches into *something*, whatever that something winds up being. >> >>So, if Clarity is going to take into consideration the building of RIAs >>at its core, than I for one will be interested in how it evolves. IF >>that isn't a central theme though, then it's DOA from my perspective. >> >>All of the frameworks involved do many things right, so it would seem >>logical to me that as long as you choose the things that work to merge, >>the end result should be pretty good. I would start by getting input >>from the community on what aspects of the contributing frameworks they >>feel truly work and are must-haves for a next-generation framework. >>Heck, the results of such a question could wind up being your goal >>statement entirely :) >> >>I would also make the point that Struts is the market leader for good >>reason and so I would hope it isn't the fourth banana in the group. >>Some people seem to believe that Struts is obsolete, or is rapidly >>becoming so, is showing it's age, etc. I believe this is only the case, >>if in fact it is, because it has been allowed to stagnate a bit in terms >>of truly evolving. It has been on autopilot for way too long and other >>frameworks have had a chance to pass it by. Be that as it may, the >>point is that I believe for a new framework to be successful it should >>take more cues from Struts on what TO do rather than what NOT to do. >>Anything less is, IMO, foolishly ignoring the reputation and community >>and success that Struts has enjoyed. >> >>Those are my initial thoughts. In any case, I offer my sincerest Good >>Luck in the endeavor, I'll be interested to see how it goes. >> >>-- >>Frank W. Zammetti >>Founder and Chief Software Architect >>Omnytex Technologies >>http://www.omnytex.com >>AIM: fzammetti >>Yahoo: fzammetti >>MSN: [EMAIL PROTECTED] >> >>Don Brown wrote: >> >> >>>Consolidation is a relatively unknown concept in the crowded web >>>framework space. While most frameworks are open source allowing >>>cross-pollination, collaboration is still rare resulting in duplicated >>>efforts and confusion for the end user. Struts Ti, a next-gen project >>>in the Struts sandbox, tried to buck the trend by building on WebWork >>>rather than wasting its time writing yet another Model2 framework. >>> >>>Taking this level of cooperation to the next level, developers from four >>>popular web frameworks - Struts, Spring, WebWork, and Beehive, have >>>gotten together to discuss the possibility of consolidating their >>>efforts into a new project, termed Clarity. Clarity would be an >>>action-based MVC framework that combines the commonality of the four >>>aforementioned frameworks into one that can be built upon by all. >>> >>>These discussions have just began, and while no one has "officially" >>>signed on, I thought I should bring it before the Struts community for >>>feedback. There is still much to work out, but I want to keep the >>>community involved from the beginning. >>> >>>I personally am excited about this project and think it will be >>>beneficial to users and developers alike. The Struts Classic code base >>>is showing its age, but speaking as a developer who maintains old Struts >>>apps, few people have the time and budget to rewrite them from scratch >>>with a more disparate framework like Shale or Wicket. I think Clarity >>>would be a much easier migration for existing Struts applications and >>>developers, yet support key standards like Portlets and JSF. >>> >>>Attached is two messages in a private email thread between Patrick >>>Lightbody (WebWork), Keith Donald (Spring), Rich Feit (Beehive), and me, >>>that started the Clarity discussion. We plan to have a public email >>>list for Clarity discussion, but it hasn't been setup yet. >>> >>>What I'm looking for from the Struts community is if you think this is a >>>good idea, and if you do, what we need to do to make it work. >>>Personally, I don't expect Struts or even Struts Classic going away at >>>all even if we agreed Clarity is migration path, so this isn't an >>>either/or discussion. >>> >>>Again, this is _NOT_ a project announcement meant for the world, only >>>the beginning of a discussion about the idea of consolidating a few web >>>frameworks and how Struts fits in with this. Looking forward to the >>>comments, >>> >>>Don >>> >>>=== Initial kickoff by Patrick Lightbody from WebWork === >>>Patrick Lightbody wrote: >>> > (Warning: long email ahead. Don't worry, this isn't usually my style >>> > and I'll stick to brief emails moving forward.) >>> > >>> > Hey guys -- this is the official "kickoff" of the project we've all >>> > been talking about. Keith had a great code name for the project: >>>Clarity. >>> > >>> > Before I get started, I just wanted to clarify the following people >>> > involved and what their roles are: >>> > >>> > - Keith represents the Spring team, including the Spring MVC and >>> > Spring WebFlow process. For now he will handle all the communication >>> > between this project and the rest of the Spring folks. >>> > - Jason is the primary technical representative from the WebWork team. >>> > While I can add some info, I expect Jason will offer most of the >>> > technical thoughts. Jason uses Spring and has a lot to offer here. >>> > - Don Brown is a Struts committer and represents the Struts team (or >>> > at least some of them). Don is the force behind Struts Ti and can >>> > provide a lot of insight as user of WebWork and XWork, with both a >>> > Struts and simplified "flavor" to it. >>> > - Rich represents the Beehive team and also works on the Struts Ti >>> > project. Rich will represent most of the Beehive input. >>> > - Finally, I hope to, more than anything, act as a facilitator for >>> > this whole project. Obviously I have a WebWork-slanted perspective, but >>> > I believe that facilitating this process is more important than any set >>> > of features or implementations choices. >>> > >>> > As I mentioned to you guys individually, I think the best way to move >>> > forward is to take the following steps. I've taken a stab at the first >>> > item as well. >>> > >>> > 1) Establish the rules: a small, agreed upon list of rules that we >>> > promise to adhere to while working on this project. These will be >>> > especially important in the early phases. >>> > >>> > 1) Complete a statement: we need to come up with a single paragraph >>> > that sums up this effort. It should include the desire to work >>> > together, the desire for clarity in the java web space, and the desire >>> > to move beyond "petty" differences about implementation choices. In >>> > short, this mission statement, when releases as a press release to the >>> > entire community, should be powerful enough to get everyone excited >>> > about it and know for sure that _this_ is the effort that will bring >>> > web development productivity back to the Java camp. >>> > >>> > 2) Announce the project: we need to gather excitement around this as >>> > soon as possible. Doing so will not only get us early feedback from the >>> > community, it will most likely stave off a few more web frameworks from >>> > being created (I found two more just today - eek!). >>> > >>> > 3) Set up a neutral place to host the project, including SVN, wiki, bug >>> > tracker, etc. This place must be detached from Jakarta/Struts, Spring, >>> > and OpenSymphony and must stay that way until we all feel comfortable >>> > working together. That will likely happen about half way through >>>step 4... >>> > >>> > 4) Now for the hard part: map out a technical implementation. >>> > >>> > 5) Release and re-establish Java as the place to build web >>> > applications. I hope for this to happen within 8-12 months time, >>> > starting today. >>> > >>> > So here are my ideal set of rules. Please adjust as you see fit: >>> > >>> > - Above all else, we recognize that consolidation is the overriding >>> goal. >>> > - We recognize that we'll all have to compromise on items we are >>> > passionate about, but that the overall project success is more >>>important. >>> > - This project aims to unify WebWork, Struts, Spring MVC, Beehive, and >>> > Spring WebFlow in to a single project that establishes clear leadership >>> > in the web development space. >>> > - All project leaders understand that once this project is releases, >>> > future work their own projects should cease (other than supporting it, >>> > minor releases, migration path to Clarity, etc). >>> > - Technical disputes should be coordinated by those _least_ familiar >>> > with the topic, and therefore least biased. >>> > - When criticizing or proposing alternatives or otherwise "stopping >>> > forward progress" - we promise to ask ourselves if this issue we're >>> > about to raise is really "worth it". >>> > - We recognize that not everyone works the way we do and we understand >>> > that we may have to work hard to find common ground. >>> > >>> > So what's next? Let's nail down the rules and then move on to a mission >>> > statement that we can announce. Remember: once we announce this, >>> > there's no going back, so let's spend some time on the rules and the >>> > mission statement. For now, please email back and forth any >>> > edits/additions to the rules. >>> > >>> > This is really exciting! Sorry for the long email and the (likely very) >>> > bureaucratic approach I'm taking with this -- I hope it adds some >>>value. >>> > >>> > Patrick >>> >>>=== Keith Donald from Spring Web Flow/MVC === >>> >>>Keith Donald wrote: >>> > I think a good first step is to clearly state what we all expect to >>>gain out >>> > of working together, given the dynamics of this market, and what our >>> > individual expectations are: >>> > >>> > Here's my take: >>> > -------------- >>> > If you look at the open source web framework market, I see these camps: >>> > >>> > 1. Action-centric (Struts Classic, Struts Ti, Spring MVC, WW, SWF, >>>Beehive) >>> > 2. Component-centric (JSF-based <Struts Shale, JBoss Seam>, Tapestry, >>> > Wicket, Echo) >>> > 3. Ruby on Rails >>> > >>> > Options in camps #2 and #3 represent considerable more shock to adopt >>>than >>> > those in #1. This is for various reasons, but mainly because the >>>majority >>> > of the market (existing Struts users) can more naturally migrate to the >>> > other action-centric frameworks. Spring MVC, for example, has been >>> > positioned as a more extensible Struts and that strategy has proven >>>fairly >>> > effective. Spring Web Flow, is usable as a component from within both >>> > Struts classic and Spring MVC, and that too has proven effective. >>>Beehive >>> > is built on Struts. >>> > >>> > So there is definite overlap (and some compliment, too) between Struts, >>> > Spring MVC, WW, SWF, and Beehive, and I think it's fair to say we share >>> > similar goals for tackling the same problems. Because of this, there >>>is a >>> > natural fit for consolidation/collaboration, motivated more now by two >>> > external forces: >>> > >>> > 1. Camps #2 and #3 are threats. RoR is one, JBoss Seam is another. >>> > >>> > 2. The market is fragmented, and that creates user confusion. There >>>is no >>> > clear "next paradigm" <is JSF the base for that or not?>, and that >>>creates >>> > (encourages?) opportunity for new entrants with little invested thus >>>far to >>> > jump in and steal the show (look what Seam is trying to do, and the >>>RoR hype >>> > coming from high-profile independents in the Java community). >>> > >>> > -- >>> > >>> > So the "clarity" project in my mind should be about providing a clear >>>"next" >>> > choice in the web-space for the Struts Classic, TI, WW, Beehive, and >>>Spring >>> > communities, with the premise being we'd be a lot stronger together >>>than we >>> > would competing with one another in essentially similar (but slightly >>> > different) ways. >>> > >>> > From my perspective, I think it's important to market a full-stack >>>product, >>> > "clarity", which unites our respective brands/technologies; however, >>>I feel >>> > it's just as important that such a stack be built from a set of >>> > best-of-breed components that lends itself to choice. For example, we >>> > wouldn't want to just ignore JSF, it's not going away (and that is >>>exactly >>> > why Spring has made JSF integration a high priority, integrating SWF >>>as a >>> > more powerful JSF NavigationHandler). >>> > >>> > The ultimate goal, though, would be to win on the full-stack, the >>>"clarity" >>> > brand, appealing to a message of simplicity comparable to RoR but >>>without >>> > the shock. >>> > >>> > Interface21 would be willing to fund marketing and technical effort >>>behind >>> > this (including hosting infrastructure), hopefully with the support >>>of BEA >>> > as well. >>> > >>> > -- >>> > >>> > From Spring's perspective there are a couple of expectations/issues I >>>want >>> > to get out there: >>> > >>> > - Spring in general has moved from being the gem of the technology >>> > enthusiasts to more of a rock for the pragmatists (early majority). >>>This is >>> > more of the case for Spring's middle ware stack (IoC/TX/DAO/etc), but >>>Spring >>> > MVC also applies to some degree as it is shipped with the core >>>framework. >>> > Among other things, this means Interface21 and BEA are now in the >>>business >>> > of providing Spring support/training/certification, and that entails >>> > contractual obligations for supporting existing versions of Spring. >>>So work >>> > on any part of the framework just can't stop on a dime: we must >>>continue to >>> > support our customers. Backwards compatibility, as well as the >>>ability to >>> > run on existing infrastructure <JDK 1.3 or >), is very important to >>>us for >>> > this reason. >>> > >>> > With that said, however, we do expect more support work around Spring's >>> > middle ware stack, as it is more widely used than Spring MVC. So we >>>do have >>> > more flexibility for change with Spring MVC, but we just can't stop >>> > supporting it. Likewise, we'd want a "clarity" migration from Spring >>>MVC to >>> > be as easy as possible. >>> > >>> > I think ease of adoption is important to all of us, else our own >>>communities >>> > may turn on us. >>> > >>> > - Spring Web Flow represents a major investment for us in the last year. >>> > We've put much more resources into SWF than we have MVC, as MVC has >>>always >>> > been a foundation to build on while SWF is a full-featured page flow >>> > product. SWF is also at a different place in the market than MVC: as >>>a new >>> > product positioned as a breakthrough technology, it is the gem of the >>> > enthusiast at this point. We expect when it reaches 1.0 it will become >>> > widely adopted quickly, as it has considerable momentum now, and is well >>> > positioned. >>> > >>> > Given that, I see opportunity with Clarity to capitalize on synergy >>>between >>> > SWF and Beehive PF and also leverage the momentum of SWF's >>>approaching 1.0 >>> > release. I do have concerns of dilution: we wouldn't want to dilute the >>> > effort/branding we've put into SWF, and risk losing the momentum we >>>have now >>> > (or worse, giving it away to say JBoss Seam, who is trying to play >>>catchup >>> > with both of us). >>> > >>> > What I'm saying is SWF is going to be successful on its own, as a new >>> > product addressing an untapped niche, so we want to make sure we take >>> > advantage of that with Clarity without dilution... and do so quickly, >>>before >>> > other competitors have a chance to stake a claim by copying it and >>>making >>> > the clone a part of their "full stack". >>> > >>> > -- >>> > >>> > I hope this provides some insight into where Spring is coming from >>>and our >>> > interest with Clarity. I feel this is unique opportunity to come >>>together >>> > and leverage the best in each of our respective products, and unite our >>> > communities under a common brand whose development is sustained not >>>only by >>> > open source developers but commercial companies such as Interface21 >>>and BEA >>> > as well. >>> > >>> > Once we have it out in the open what we all hope to gain, I think a good >>> > next step is to start flushing out from a technical perspective what >>>this >>> > thing would look like--in the ideal, and keeping in mind migration >>>from our >>> > existing products, and the need for components at each key part in the >>> > stack. Once the technical architecture is understood, then I think it's >>> > natural to start focusing on marketing/branding. >>> > >>> > Keith >>> > >>> > -----Original Message----- >>> > From: Patrick Lightbody [mailto:[EMAIL PROTECTED] >>> > Sent: Thursday, October 06, 2005 11:20 AM >>> > To: Rich Feit >>> > Cc: Keith Donald; Don Brown; Jason Carreira >>> > Subject: Re: Project Clarity Kickoff >>> > >>> > Rich, >>> > Yes, the project of course would be open source and likely Apache 2.0 >>> > License. >>> > >>> > I agree: Our mission statement must give a high level detail of the >>> > project as well, clarifying the space. >>> > >>> > I also think the wikis/infrastructure should be open. >>> > >>> > As for technical details (step #4), when we get there we will >>> > definitely focus on framework features and characterization. I just >>> > don't want to dive in to these things yet - as some topics can and >>> > will be very contentious. That's why I'm avoiding a reply to Jason's >>> > email :) >>> > >>> > You're right -- that rule about "stopping the other projects" is >>> > simply there to make sure that we all understand that competing >>> > efforts would be ramped down. I think we all know that, so it may not >>> > even be worth stating. >>> > >>> > Patrick >>> > >>> > On Oct 6, 2005, at 12:21 AM, Rich Feit wrote: >>> > >>> > >>> >>Patrick, >>> >> >>> >>This *is* really exciting -- if Clarity comes about, it'll cut through >>> >>the confusion that's starting to dominate this space. >>> >> >>> >>I think you're setting this up really well. I have a few specific >>> >>comments, but my first is this: before I could commit Beehive to the >>> >>project, I have to be able to share it with the Beehive community, >>> >>even >>> >>at this early stage. Some kind of message that says a bunch of key >>> >>projects want to consolidate to eliminate overlap, and that this would >>> >>supplant a chunk of Beehive. Committers vote, possibly tell me to >>> >>go to >>> >>hell. I assume this isn't a problem, but I want to make sure it's out >>> >>there. (Don, I guess you're in the same boat...?) >>> >> >>> >>Some specifics inline... >>> >> >>> >>Patrick Lightbody wrote: >>> >> >>> >> >>> >> >>> >>>(Warning: long email ahead. Don't worry, this isn't usually my style >>> >>>and I'll stick to brief emails moving forward.) >>> >>> >>> >>>Hey guys -- this is the official "kickoff" of the project we've all >>> >>>been talking about. Keith had a great code name for the project: >>> >>>Clarity. >>> >>> >>> >>>Before I get started, I just wanted to clarify the following people >>> >>>involved and what their roles are: >>> >>> >>> >>> - Keith represents the Spring team, including the Spring MVC and >>> >>>Spring WebFlow process. For now he will handle all the communication >>> >>>between this project and the rest of the Spring folks. >>> >>> - Jason is the primary technical representative from the WebWork >>> >>>team. While I can add some info, I expect Jason will offer most of >>> >>>the technical thoughts. Jason uses Spring and has a lot to offer >>> >>>here. >>> >>> - Don Brown is a Struts committer and represents the Struts team >>> >>>(or >>> >>>at least some of them). Don is the force behind Struts Ti and can >>> >>>provide a lot of insight as user of WebWork and XWork, with both a >>> >>>Struts and simplified "flavor" to it. >>> >>> - Rich represents the Beehive team and also works on the Struts Ti >>> >>>project. Rich will represent most of the Beehive input. >>> >>> - Finally, I hope to, more than anything, act as a facilitator for >>> >>>this whole project. Obviously I have a WebWork-slanted perspective, >>> >>>but I believe that facilitating this process is more important than >>> >>>any set of features or implementations choices. >>> >>> >>> >>>As I mentioned to you guys individually, I think the best way to move >>> >>>forward is to take the following steps. I've taken a stab at the >>> >>>first item as well. >>> >>> >>> >>> >>> >> >>> >> 0) Agree on the software license. Without the right license >>> >>(ASF), >>> >>I'm guessing many of us wouldn't be able to participate. >>> >> >>> >>Also, a basic question. Is this an open source project? >>> >> >>> >> >>> >> >>> >>>1) Establish the rules: a small, agreed upon list of rules that we >>> >>>promise to adhere to while working on this project. These will be >>> >>>especially important in the early phases. >>> >>> >>> >>>1) Complete a statement: we need to come up with a single paragraph >>> >>>that sums up this effort. It should include the desire to work >>> >>>together, the desire for clarity in the java web space, and the >>> >>>desire to move beyond "petty" differences about implementation >>> >>>choices. In short, this mission statement, when releases as a press >>> >>>release to the entire community, should be powerful enough to get >>> >>>everyone excited about it and know for sure that _this_ is the effort >>> >>>that will bring web development productivity back to the Java camp. >>> >>> >>> >>> >>> >> >>> >>Totally. The only thing I'd add here (maybe obvious) is that this >>> >>should go beyond the desire to work together and bring clarity to the >>> >>space -- some high-level characterization of what the framework itself >>> >>is about. >>> >> >>> >> >>> >> >>> >>>2) Announce the project: we need to gather excitement around this as >>> >>>soon as possible. Doing so will not only get us early feedback from >>> >>>the community, it will most likely stave off a few more web >>> >>>frameworks from being created (I found two more just today - eek!). >>> >>> >>> >>>3) Set up a neutral place to host the project, including SVN, wiki, >>> >>>bug tracker, etc. This place must be detached from Jakarta/Struts, >>> >>>Spring, and OpenSymphony and must stay that way until we all feel >>> >>>comfortable working together. That will likely happen about half way >>> >>>through step 4... >>> >>> >>> >>> >>> >> >>> >>It would be as open as the wikis, mailing lists, repositories, etc. of >>> >>the rest of the projects, right? >>> >> >>> >> [additional item -- maybe falls under #4] Agree on general features >>> >>and characteristics of the framework. Some examples (note: I'm not >>> >>assuming everyone would agree to these particular ones :) ): >>> >> - support entities that are flow controllers as first class >>> >>citizens >>> >> - support the association of per-user state with a flow controller >>> >> - allow Java 5 annotations as a way to configure controllers >>> >> - provide a fast no-redeploy iterative dev experience >>> >> >>> >> [additional item -- maybe falls under #4] Mock up some files/ >>> >>artifacts >>> >>as the user would see/write them. Like what Don did early on in Ti >>> >>(http://wiki.apache.org/struts/StrutsTi/ControllerMock ). >>> >> >>> >> >>> >> >>> >> >>> >>>4) Now for the hard part: map out a technical implementation. >>> >>> >>> >>>5) Release and re-establish Java as the place to build web >>> >>>applications. I hope for this to happen within 8-12 months time, >>> >>>starting today. >>> >>> >>> >>>So here are my ideal set of rules. Please adjust as you see fit: >>> >>> >>> >>> - Above all else, we recognize that consolidation is the overriding >>> >>>goal. >>> >>> - We recognize that we'll all have to compromise on items we are >>> >>>passionate about, but that the overall project success is more >>> >>>important. >>> >>> - This project aims to unify WebWork, Struts, Spring MVC, Beehive, >>> >>>and Spring WebFlow in to a single project that establishes clear >>> >>>leadership in the web development space. >>> >>> - All project leaders understand that once this project is >>> >>>releases, >>> >>>future work their own projects should cease (other than supporting >>> >>>it, minor releases, migration path to Clarity, etc). >>> >>> - Technical disputes should be coordinated by those _least_ >>> >>>familiar >>> >>>with the topic, and therefore least biased. >>> >>> - When criticizing or proposing alternatives or otherwise "stopping >>> >>>forward progress" - we promise to ask ourselves if this issue we're >>> >>>about to raise is really "worth it". >>> >>> - We recognize that not everyone works the way we do and we >>> >>>understand that we may have to work hard to find common ground. >>> >>> >>> >>> >>> >> >>> >> The rules... I agree, for us to succeed, we need these. We'll all >>> >>have to take as a prime goal compromise/progress over dogma. My main >>> >>comment is about consolidation and ceasing development on the ancestor >>> >>projects. Beehive has components that I assume are far outside the >>> >>mission of Clarity (e.g., JSR 181 Web Services Metadata >>> >>implementation). Just want to make sure we're not trumpeting the >>> >>death >>> >>of entire frameworks that don't overlap. Relatedly, I feel that the >>> >>cease-development clause should go something like this: >>> >> "... will cease developing features that overlap with features >>> >>in Clarity." >>> >> It's clearly not in the interest of any project to keep plugging >>> >>along with a redundant framework (c'mon, how can you compete with >>> >>Clarity? :) ), but I imagine that many features will fall outside the >>> >>scope of what's done here. >>> >> >>> >>A final question: would people agree that we should start core/focused >>> >>(e.g., controller tier, view agnostic, not trying to define an entire >>> >>stack)? Seems like this is something that would help us move forward >>> >>more quickly, and would prevent us from trying to make too many leaf >>> >>nodes part of the trunk. >>> >> >>> >> >>> >> >>> >>>So what's next? Let's nail down the rules and then move on to a >>> >>>mission statement that we can announce. Remember: once we announce >>> >>>this, there's no going back, so let's spend some time on the rules >>> >>>and the mission statement. For now, please email back and forth any >>> >>>edits/additions to the rules. >>> >>> >>> >>>This is really exciting! Sorry for the long email and the (likely >>> >>>very) bureaucratic approach I'm taking with this -- I hope it adds >>> >>>some value. >>> >>> >>> >>>Patrick >>> >>> >>> >>> >>> >> >>> >>Exciting stuff! >>> >> >>> >>Rich >>> >> >>> > >>> > >>> > >>> >>> >>> >>> >>>--------------------------------------------------------------------- >>>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] >> >> >> >> > > >-- >"You can lead a horse to water but you cannot make it float on its back." >~Dakota Jack~ > >--------------------------------------------------------------------- >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]
