Mailing-List: contact dev-help@beehive.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Beehive Developers" <dev@beehive.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of richfeit@gmail.com designates
 64.233.162.201 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:content-type;
        b=MRvvgIYOPBQKuk73EKi0DgM4QasrChXXZ55x0boXKrSGyYZIGAhzWfNa9tWHOMGzGzboMySwf0ceZsc13E73lVjQIlYS2hg/5mPzOmnWJdWzeWfFrrdkSH6m6SH9YS4GroLHqtIjtKnl2+tPj0sehUynTglHN8CIctQsrWUhvgs=
Message-ID: <434AB4C8.8050703@gmail.com>
Date: Mon, 10 Oct 2005 12:36:56 -0600
From: Rich Feit <richfeit@gmail.com>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
MIME-Version: 1.0
To: dev@beehive.apache.org
Subject: Beehive/Spring/Struts/WebWork
Content-Type: multipart/mixed;
 boundary="------------040902050803030202020500"

--------------040902050803030202020500
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hi all,

I've been on a bunch of emails about the idea of a new web framework that would somehow unify Beehive, Spring, Struts and WebWork -- at least the parts of all these projects that overlap.  As far as I know, none of these groups has officially signed onto any such idea, and the parameters of the project definitely have not been hashed out yet.  I'm wondering what sorts of reactions people here have to the idea at this stage.  If it happens, should Beehive be involved?  Are there parameters that would make this a good thing for Beehive to join?

We had a brief exchange about this on the PMC this weekend, mostly to confirm that it's a discussion that we should have on this list.  So here we are.

Some notes:

    - I'm attaching the initial email I got from Patrick Lightbody (WebWork), along with another from Keith Donald (Spring).  I forwarded the entire chain to the PMC and it was apparently overwhelming and of marginal value, so I'll try to limit it to important messages.

    - I want to stress that *if* this is something we should be a part of, then it is up to us (the Beehive community) to establish the ways in which we would need this to work.  Other projects will have other opinions/needs.  If we do this, I think that scoping the project and setting it up will be the hardest parts.

    - I am currently on a private thread with four other people about this.  As you'll see from the original email, they're trying to keep the discussion limited to one representative from each project until there's resolve to go forward with it.  I'm actually in favor of the project -- I think it would be good for Beehive and for the community at large -- but as this discussion shapes up, I would like to be replaced by someone who's more skeptical.  I think this will help us move forward (the whole Nixon/China thing :) ).

    - The attached email from Keith is a technical exchange he and I had about how Beehive Page Flow and Spring Web Flow could be integrated.  One of our PMC members expressed concern about this, so I wanted to include it and to assert that this isn't committing us to anything.  It was meant to be an exploration of whether we could work together, and I think it's enough to show that we can.  For now, I'll drop this discussion until we have a clearer idea of Beehive's involvement.  

It's really important that we figure out if (and *how*) this would work for Beehive.  Let me know what you think.

Thanks,
Rich


--------------040902050803030202020500
Content-Type: message/rfc822;
 name="Attached Message"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="Attached Message"

X-Account-Key: account3
Mime-Version: 1.0 (Apple Message framework v733)
To: Rich Feit <richfeit@gmail.com>
Cc: Keith Donald <keith@interface21.com>, Don Brown <mrdon@twdata.org>,
 Jason Carreira <jason@zenfrog.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
References: <C55AB0C0-648F-4651-876B-3071CF58D099@gmail.com>
 <4344D080.1080502@gmail.com>
X-MB-Message-Source: ExternalSMTP
Received-SPF: pass (gmail.com: domain of plightbo@gmail.com designates
 66.249.82.193 as permitted sender)
X-MB-Message-Type: User
Content-Transfer-Encoding: 7bit
X-MB-Recipient-Addr-Type: ExternalForward
Message-Id: <DEDCD649-C03D-4F99-AA19-246ADF3E69A2@gmail.com>
X-Forwarded-To: richfeit@mailblocks.com
Return-Path: <richfeit+caf_richfeit=mailblocks.com@gmail.com>
X-Mailer: Apple Mail (2.733)
X-MB-Trace: IMM:FromExtSMTP,09D7E60C-42139FF1-3117659F-32489472 TRK:NTrckr
 AV:NA AFS:NP UAR:Acpt,Org,PA"plightbo@gmail.com",A GARPostUser:WD_NP
 DTKT:WD_NP DTKTR:WD_NP CR:WD_NP DDisp:WD_NP
Received: from 10.10.0.94 by app22.mailblocks.com (10.10.0.71) with SMTP for
 richfeit@gmail.com; Thu, 06 Oct 2005 08:58:20 -0700
Received: (qmail 11410 invoked from network); 6 Oct 2005 15:58:17 -0000
Received: from 72.14.204.203 (HELO qproxy.gmail.com) (72.14.204.203)  by
 140.174.9.94 with SMTP; 6 Oct 2005 15:58:17 -0000
Received: by qproxy.gmail.com with SMTP id p26so379335qbb        for
 <richfeit@mailblocks.com>; Thu, 06 Oct 2005 08:58:13 -0700 (PDT)
Received: by 10.64.185.6 with SMTP id i6mr1007547qbf;
        Thu, 06 Oct 2005 08:58:13 -0700 (PDT)
Received: by 10.65.43.10 with SMTP id v10cs2089qbj;
        Thu, 6 Oct 2005 08:58:13 -0700 (PDT)
Received: by 10.54.91.3 with SMTP id o3mr1390792wrb;
        Thu, 06 Oct 2005 08:19:10 -0700 (PDT)
Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.193])        by
 mx.gmail.com with ESMTP id 14si1739790wrl.2005.10.06.08.19.49;
        Thu, 06 Oct 2005 08:19:50 -0700 (PDT)
Received: by xproxy.gmail.com with SMTP id t16so292161wxc        for
 <richfeit@gmail.com>; Thu, 06 Oct 2005 08:19:49 -0700 (PDT)
Received: by 10.70.15.13 with SMTP id 13mr1379874wxo;
        Thu, 06 Oct 2005 08:19:48 -0700 (PDT)
Received: from ?192.168.1.102? ( [24.22.6.210])        by mx.gmail.com with
 ESMTP id h15sm1228989wxd.2005.10.06.08.19.47;
        Thu, 06 Oct 2005 08:19:48 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;        s=beta; d=gmail.com;
        h=received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer;
        b=PXuL8bGw/isz0NfomPycRjnGdYS843Hs4/fFx25wcL93BOgxnFDHYiEEAkgU1B/t7afMcd/S18lhm46U5hl70uOMhMLCLmRJoyJAN2PlZcwRvfJec6R2teKs+k5vqJvDFTOharnBQ0waoXTeqPy91+QicxbvUwO06qTvYCI2+BE=
Date: Thu, 6 Oct 2005 08:20:02 -0700
From: Patrick Lightbody <plightbo@gmail.com>
X-Gmail-Received: 1ed1ecb13f3fc75d076de80bcba8c8378ee3a6e3
Subject: Re: Project Clarity Kickoff
In-Reply-To: <4344D080.1080502@gmail.com>
DomainKey-Status: good (test mode)
X-MB-Recipient-Addr: richfeit@gmail.com
X-Forwarded-For: richfeit@gmail.com richfeit@mailblocks.com
X-MB-Envelope-From: <richfeit+caf_richfeit=mailblocks.com@gmail.com>
Delivered-To: richfeit@gmail.com

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
>


--------------040902050803030202020500
Content-Type: message/rfc822;
 name="Attached Message"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="Attached Message"

X-Account-Key: account3
In-Reply-To: <43494DDA.8070601@gmail.com>
MIME-Version: 1.0
To: "Rich Feit" <richfeit@gmail.com>
Cc: "Keith Donald" <keith@interface21.com>, "'Don Brown'" <mrdon@twdata.org>,
 "'Patrick Lightbody'" <plightbo@gmail.com>,
 "'Jason Carreira'" <jason@zenfrog.com>
Content-Type: text/plain;charset=iso-8859-1
References: <43482a93.47b486c9.1b0d.0f02SMTPIN_ADDED@mx.gmail.com>
       <43483B5F.1020005@gmail.com>
    <1347.65.33.245.127.1128812353.squirrel@web2.springframework.com>
    <43494DDA.8070601@gmail.com>
X-MB-Recipient-Addr: richfeit@gmail.com
Received-SPF: neutral (gmail.com: 63.246.7.10 is neither permitted nor denied
 by best guess record for domain of apache@springframework.com)
X-MB-Recipient-Addr-Type: ExternalForward
Content-Transfer-Encoding: 8bit
X-MB-Envelope-From: <richfeit+caf_richfeit=mailblocks.com@gmail.com>
X-MB-Trace: IMM:FromExtSMTP,09D7E60C-42139FF1-3117659F-32489472 TRK:NTrckr
 AV:NA AFS:NP UAR:Acpt,Org,PA"apache@springframework.com",A GARPostUser:WD_NP
 DTKT:WD_NP DTKTR:WD_NP CR:WD_NP DDisp:WD_NP
Message-ID: <1617.65.33.245.127.1128882752.squirrel@web2.springframework.com>
X-Forwarded-To: richfeit@mailblocks.com
Return-Path: <richfeit+caf_richfeit=mailblocks.com@gmail.com>
X-MB-Message-Source: ExternalSMTP
Received: from 10.10.0.93 by app22.mailblocks.com (10.10.0.71) with SMTP for
 richfeit@gmail.com; Sun, 09 Oct 2005 11:32:36 -0700
Received: (qmail 504 invoked from network); 9 Oct 2005 18:32:36 -0000
Received: from 72.14.204.193 (HELO qproxy.gmail.com) (72.14.204.193)  by
 140.174.9.93 with SMTP; 9 Oct 2005 18:32:36 -0000
Received: by qproxy.gmail.com with SMTP id a33so1032716qbd        for
 <richfeit@mailblocks.com>; Sun, 09 Oct 2005 11:32:34 -0700 (PDT)
Received: by 10.64.241.9 with SMTP id o9mr2036615qbh;
        Sun, 09 Oct 2005 11:32:34 -0700 (PDT)
Received: by 10.65.43.10 with SMTP id v10cs33681qbj;
        Sun, 9 Oct 2005 11:32:34 -0700 (PDT)
Received: by 10.36.66.15 with SMTP id o15mr2890734nza;
        Sun, 09 Oct 2005 11:32:34 -0700 (PDT)
Received: from gate.springframework.com (63-246-7-10.contegix.com
 [63.246.7.10])        by mx.gmail.com with ESMTP id
 38si1801229nzf.2005.10.09.11.32.34;
        Sun, 09 Oct 2005 11:32:34 -0700 (PDT)
Received: from apache by gate.springframework.com with local (Exim 4.41)	id
 1EOfyK-0001XP-4o; Sun, 09 Oct 2005 13:32:32 -0500
Received: from 65.33.245.127        (SquirrelMail authenticated user keithd)
        by web2.springframework.com with HTTP;
        Sun, 9 Oct 2005 13:32:32 -0500 (CDT)
X-MB-Message-Type: User
Sender: <apache@springframework.com>
Date: Sun, 9 Oct 2005 13:32:32 -0500 (CDT)
From: "Keith Donald" <keith@interface21.com>
X-Gmail-Received: d8f7123563378a6036c8ff326dec4ec50fd69139
Subject: Re: Project Clarity Kickoff
X-Forwarded-For: richfeit@gmail.com richfeit@mailblocks.com
User-Agent: SquirrelMail/1.4.4
Importance: Normal
X-Priority: 3 (Normal)
Delivered-To: richfeit@gmail.com

Rich,

I imagine I'm missing something in Beehive's case, but in SWF's case:

- For the XML flow definition format, DTD validation catches "compile
time" errors quite nicely.  Supplimented with a flow editor, like what the
Spring IDE team is working on, and you can do more of course, but plain
old DTD validation takes care of the most common 80% for sure.

- At runtime, an out-of-container test of the Flow execution catches any
runtime logic errors in the flow, allowing you to test all paths through
the flow from a JUnit test.  So you can code your flow, run the test, see
it fail, revise, run the test, see it fail again, revise, run the test,
see *green bar* ... then deploy the flow for execution in container.

For an annotation-driven format, the Java 5 compiler would catch most
errors, as well, right? What other compile-time processing happens beyond
what the compiler does?

Keith

> Excellent.  Yeah, as things progress, people aren't going to accept
> anything less than a kickass iterative dev experience.  I do think that
> #1 is just as important, though; it allows you to see all errors and
> warnings in the entire app.  If it "compiles" fully, then you've got
> something that won't blow up at runtime (or, the blowups are confined to
> logic errors).  You also have a more transparent translation of the
> annotations into something the runtime will consume.  I'd just propose
> that we do both.  The annotation processing layer is the most known
> quantity here; getting the runtimes to match up will be the core of the
> work.
>
> Rich
>
> Keith Donald wrote:
>
>>Cool!  I look forward to helping you work through this.
>>
>>You probably already know this, but just in case: SWF has no buildtime
>>step.  Rather, flow definitions represented in Xml or Java are parsed
>> into
>>configured org.springframework.webflow.Flow instances by their respective
>>FlowBuilder implementation at runtime.
>>
>>Once you have a configured webflow.Flow, you have everything, as that is
>>the core object in the system.  More specifically, with a webflow.Flow in
>>hand you can then create a FlowExecution which represents *exactly one*
>>user conversation (implemented internally as a finite state machine) and
>>start signaling events against it.
>>
>>As you mention, our customers really like this because it lends it self
>> to
>>agile/iterative development.  There is no special code generation /
>>compilation step, and it is straightforward to add support for
>>hot-reloadable flows.  In addition, FlowExecutions are extremely natural
>>to test.
>>
>>So I would certainly favor determing the feasibility of option #2 as a
>>priority over option #1.
>>
>>Keith
>>
>>
>>
>>>I agree -- I'm sure there would be some obstacles to clear (impedance
>>>mismatch in some areas), but it would be a great place to start.
>>>
>>>Assuming that a Beehive page flow could be expressed as a SWF Flow, I
>>>see two main ways to build the Flow:
>>>    1) At build time, when running under apt (or XDoclet -- we can
>>>support both).  In this case I think we'd just generate to your XML
>>>format.
>>>    2) At runtime, where the Page Flow checker/generator would run in a
>>>FlowBuilder.  This would be great for iterative dev.
>>>
>>>I think this is definitely worth exploring.
>>>
>>>Rich
>>>
>>>Keith Donald wrote:
>>>
>>>
>>>
>>>>If a Beehive PF could be straightforwardly engineered into a SWF Flow
>>>>definition (an instance of the class org.springframework.webflow.Flow),
>>>>that
>>>>would be a natural integration point.
>>>>
>>>>SWF has a very complete API for expressing a Flow (rich with behavior
>>>> as
>>>>well, not just data).  It also includes a pluggable FlowBuilder
>>>> strategy
>>>>for
>>>>to constructing those Flow definitions.  Current implementations
>>>> support
>>>>construction from a XML definition, Java code, or a Groovy script
>>>>(org.springframework.webflow.config.FlowBuilder's class hierarchy for
>>>>details).
>>>>
>>>>Does a BeehiveFlowBuilder that builds a Flow from an annotated JavaBean
>>>>make
>>>>sense?  That seems quite ideal, as we could leverage the flexible
>>>>architecture of SWF with the existing toolability/compatability of the
>>>>Beehive PF format.
>>>>
>>>>Keith
>>>>
>>>>-----Original Message-----
>>>>From: Rich Feit [mailto:richfeit@gmail.com]
>>>>Sent: Saturday, October 08, 2005 12:16 PM
>>>>To: Keith Donald
>>>>Cc: 'Don Brown'; 'Patrick Lightbody'; 'Jason Carreira'
>>>>Subject: Re: Project Clarity Kickoff
>>>>
>>>>Keith Donald wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>>I'd like to see Clarity be
>>>>>>"more Shale than Shale", in providing a strong controller that
>>>>>>compliments
>>>>>>JSF, yet can work with other view technologies.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>Exactly, I totally agree.  We also have JSF/SWF integration examples,
>>>>>and
>>>>>Craig has been helping Colin and I with the integration (which is
>>>>> moving
>>>>>along nicely).
>>>>>
>>>>>Beehive and SWF--how can the two be combined?
>>>>>
>>>>>Keith
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>If Beehive is a part of Clarity, then I imagine this would be the
>>>>hardest integration task.  But I've been looking at SWF, and I think
>>>>it's possible that (some modification of) Beehive Page Flow could be
>>>>built on (some modification of) Spring Web Flow.  After all, much of
>>>>Page Flow is about annotated JavaBeans that encapsulate flow/state.
>>>>This isn't incompatible with SWF's way of doing things -- possibly an
>>>>optional layer above it.
>>>>
>>>>Accomplishing this would take some sincere effort (and compromise) from
>>>>both sides, but it's likely doable.
>>>>
>>>>Rich
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>>
>


-- 
Keith Donald
Principal Consultant, Interface21
http://www.springframework.com - Spring Services From the Source


--------------040902050803030202020500--