Thanks for the response, Daryl. I think the Clarity folks realized that they were biting off more than they could chew, so they reduced the scope. Clarity will first focus at the level of Struts/WebWork/Spring MVC, without something like Page Flow. The Beehive community can remain an observer for now (assuming we don't want to try and contribute our tags as their view layer :) ).
Rich Daryl Olander wrote: >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. >> >> >> >> >> > > >
