Martin Cooper wrote:

>I actually think there are a number of rather independent ideas here, which
>should probably be treated as such.
>
>1) Resource sharing. In some application scenarios, it is desirable to share
>(some) data sources, message resources, etc., across all of the modules in
>the application. This relates more to application-wide (as opposed to
>module-wide) configuration than it does to module inheritance.
>
Yes - possibly, but not necessarily.

>2) Inter-module communication. On the surface, sharing "truly global" global
>forwards seems similar to (1) above. The difference, however, is that there
>is now explicit interaction between modules, and in particular, a shared
>resource which "knows" about the modules which are part of the application.
>
... but why would it have to be a shared resource?  ... or are you 
calling the default sub-app a "shared resource"?

>3) Hierarchical applications. This *might* be a scenario in which the
>default module becomes a "framework" that other modules plug into, but it
>might be something else entirely. For example, there is no real reason to
>treat the default module as the root of the hierarchy.
>
It just seemed a natural fit - but, ok.  My reasoning was in the way we 
key things:  Same key in request (for current module) and application 
(for default) makes it easy to chain this way.

>As you know, I happen
>to have implemented a hierarchical app that way (actually, it turned out to
>be a directed graph, but I'm not about to explain that :), and I fear that
>my spouting about that may have unduly influenced others' thinking about how
>hierarchical applications should be built. Just because I made it work
>doesn't mean it's the right/best way to do it!
>
Don't take all the blame upon yourself :-)  I'd been "feeling" that way 
every since I really started experimenting with "what sub-apps really 
meant".  You did, I suppose, reaffirm that those were "good feelings" - 
but they didn't originate with you ;-)

>Note that while a hierarchical application may take advantage of (1) and
>(2), it may also achieve its goals in an entirely different way. That's why
>I think these ideas are largely independent.
>
Yes, but I think this is a "natural fit".  Of course, the way you say 
that makes me think you have a card you're holding til the last hand is 
dealt ;-)

>In any case, I agree with Craig that this is a post-1.1 topic. As I've said
>before, we really need to get the modular application concept out there and
>see what people do with it. Then we can have a more general discussion of
>how Struts in general, and the module concept in particular, can be expanded
>to address peoples' needs.
>
Right.  As I said, I was looking to get feedback.  I really hoped there 
would be some meaningful discussion.  It's now obvious to me though 
(blatantly) that such discussion is counter-productive to what our 
actual goal should be:  getting 1.1 out the door.  I do look forward to 
that event though :-) ... because then there will necessarily be 
speculation on how the next release should be dealt with - which 
features should (not) be included... and I look forward to being 
involved in those discussions ;-)

>--
>Martin Cooper
>

-- 
Eddie Bush




--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to