Those are exactly the type of questions I was writing concurrently Adam - 
thanks for bringing them up.  My off the cuff response is that this isn't 
tomcat or jboss - it runs in the containers, but is not one itself, so what 
exactly would the framework do without an application sitting on top of it?  I 
think that we should start looking at positioning this somewhat like what a 
JBoss stack implementation might look like - examples for Seam, examples for 
Hibernate, examples of security implementations, possibly even examples of 
content management / use of Webslinger, etc, etc.  

This would put it up favorably against what the framework "competition" looks 
like - and would likely show how much easier it is to develop applications in 
OFBiz vs some of these other frameworks that are supposed to be simple for 
people to use.

Cheers,
Ruppert
--
Tim Ruppert
HotWax Media
http://www.hotwaxmedia.com

o:801.649.6594
f:801.649.6595

On Jan 2, 2010, at 1:55 PM, Adam Heath wrote:

> Ean Schuessler wrote:
>> Adrian Crum wrote:
>>> I don't agree that emailing forgotten passwords is like the Webtools
>>> application. As you have discovered, emailing forgotten passwords
>>> entails some decision making, looking up information in various
>>> entities, selecting and rendering an email body template, etc. From my
>>> perspective, all of those things are outside the scope of the framework.
>> 
>> I agree. It is easy to imagine that some applications would not allow a
>> password to be reset via email. It might be that the application uses
>> biometrics, cryptographic signatures or who knows what. The framework
>> authentication stubs should accommodate a diversity of approaches.
>> 
>> One major question is whether framework, on its own, should even be
>> runnable as an application. In my opinion, it is a library, not an app
>> and doesn't need to be operational on its own.
> 
> What is your definition of operational?  A servlet container that is
> listing for requests on 8009, 8080?  Ready to process rmi requests?
> 
> Is framework a *pure* library, where the application that runs on top
> of it is responsible for starting any long-term, background services,
> or should framework be the application wrapper?

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to