Hoping to kick off a bit of a discussion here, I'll start from the stated "rules", though these seem to be a bit of both rules and goals....
I'm not sure that I see a lot of need for consolidation in this market. It seems to me like Beehive NetUI has hit a sweet spot. We are already integrated directly with struts and provide a bunch of V2 Web Framework support such as meta data, automatic state management, and nesting; too name a few. In addition, we support multiple view technologies and have good integration with JSF. I've haven't seen Beehive users demand for integration or support of either Spring WebFlow or WebWork. They have asked for AJAX, structs migration, etc. In addition, I'm not sure what means to consolidate these frameworks. Does it mean that the Struts XML configuration file, SWF Flow Definition and an annotated page flow all continue to exist? Or do we take the "ideas" embodied in these projects (actions, flow, etc) and move them into a new light weight framework and simply provide a migration from existing projects? In today's model for NetUI, we have almost a duel Meta data model at the implementation level (struts config files and annotations in the page flow), but a single programming model (annotations). In a consolidated world are we consolidating at the programming model, configuration and/or API level? There are a number of other frameworks that are stacking out territory in this world (JSF/myFaces, Shale, and Seam), should we consider bringing them in? There are bunches of smaller frameworks that certainly have interesting properties (Tapestry) or large number of users (velocity). These aren't represented here either. Consolidation is an interesting goal, but why choose some and not others? Overall it seems to me, that being at the "top" of the stack, having a number of choices is good for users. There is less technical reason for consolidation at this level. You can pick your framework based upon the features, standards, the programming model, and the tools. Second, I'm very uncomfortable about this: - *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).* I think we cut off adoption of Beehive if we commit to any project that promises to end-of-life NetUI in the next year or two. Why adopt Beehive (or SWF) if you know that a year from now, you'll be adopting a new framework? If this is your current choice, I think you'd be better off looking hard at Shale and Seam or just continuing to use Struts and see where the dust settles. Don't we owe our current and future users our ear to listen to their requirements, criticism and suggestions and implement them to the best of our ability within our framework? Our commitment is to move them forward as the web and technology evolve (AJAX, Web 2.0, EJB 3.0, etc) Overall, I feel like Beehive would be better off moving forward. We just shipped 1.0 and we have a pile of features we can do, many of which compete directly against Shale, ASP.NET <http://ASP.NET>, RubyOnRails and Seam. If we spent a year developing some of those features we are further along than if we spend a year figuring out how to coexist with a couple of other existing frameworks. On 10/10/05, Daryl Olander <[EMAIL PROTECTED]> wrote: > > Pulling from the mail below to summerize (emphasis is mine): > > From: Patrick Lightbody <[EMAIL PROTECTED]> > To: Rich Feit <[EMAIL PROTECTED]> > Date: Thu, 6 Oct 2005 08:20:02 -0700 > Subject: Re: Project Clarity Kickoff > > ... > > 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. > > >
