Re: Moving securityext to the framework

[Ean Schuessler <ea...@brainfood.com>]

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.

Re: Moving securityext to the framework

[Bruno Busco <br...@gmail.com>]

Hi David,
inline

> Please keep in mind that is just your document. There is no such thing as implicit agreement, and if there are disagreements on the mailing list IMO that is just as valid as someone going in and changing your document (and most people would probably consider it less rude too, which is maybe why no one has made changes there).
>
> BTW, looking through those... where are the CMS related requirements? What sorts of business activities drive these requirements?
>
> Actually, to be more accurate, I wouldn't call any of the things you listed there requirements, they all look like designs to me, ie solutions to the problems rather than the problems themselves.

The end-user requirements list I have written was only intended to
start to define what the end-user will be able to do with the
framework-only.
This is what we really need right now; of course I can replace the
"can" with "shall" if you think this will help (I really don't).

The list has already been useful at least because Adrian has suggested
some changes (may be adding a comment on the Confluence page would be
better) so, please, let's continue using it and please, everybody be
rude! Add comments or even change it. I did not write having in mind
it was perfect but just a startup of the a requirements elicitation
process.

> And what about those who not only don't care either way about CMS, but really don't want to bother with CMS in the system? One way or another you're sure to get complaints...

Why should I have compliants from people that will have a CMS base
system and a set of selectable additional components that add the
functionalities they need?
The content component, as it is now, is something that cannot be
(easily) removed from OFBiz so ALL users should somehow bother with
it. Even the help system is based on the content component.

> That is an interesting opinion, and it's great that you have been looking into this. Could you share what you have based this opinion on, it might be enlightening to others too.

This comes just from what I have figured out looking a little bit at
the communities around products as Drupal, Joomla, OpenCms, Magento
etc.
I may be wrong, for sure I am far from being a web analyst. But I have
seen e-commerce modules to be pluggable into CMS products never the
other way around.

> For example, one specific idea might be to move some of the email stuff from content to the framework somewhere. Sending and receiving emails is pretty low-level, though that doesn't mean we'd want to move all of it as the CommunicationEvent stuff is definitely higher level and ties to many many other things in the system, and that's a much harder line to draw.

A similar idea is just what originated my frst mail in this thread. I
did see that the send forgotten password email is in the
application/securityext and suggested to move to framework/security.
To have the forgotten password mail in the framework we should have
the email system as well for sure. So here we are on the same page.

So moving forward now.
I have seen an even more basic item we should agree:

Do we want the framework-only to be a library only, not directly
runnable/usable without an additional application installed
or we want the framework-only to be directly usable with a few set of
functionality?

-Bruno

Re: Moving securityext to the framework

[Adrian Crum <ad...@yahoo.com>]

--- On Sun, 1/3/10, David E Jones <de...@me.com> wrote:
> On Jan 3, 2010, at 2:04 PM, Adrian Crum wrote:
> 
> > --- On Sun, 1/3/10, David E Jones <de...@me.com>
> wrote:
> >> One way or another if we're moving things around,
> >> especially moving higher level stuff into the
> framework,
> >> then we should definitely discuss it first and
> even try to
> >> reach a consensus around it.
> >> 
> >> For example, one specific idea might be to move
> some of the
> >> email stuff from content to the framework
> somewhere. Sending
> >> and receiving emails is pretty low-level, though
> that
> >> doesn't mean we'd want to move all of it as the
> >> CommunicationEvent stuff is definitely higher
> level and ties
> >> to many many other things in the system, and
> that's a much
> >> harder line to draw.
> >> 
> >> For the most part the dividing line between
> framework and
> >> the base applications is that business-driven
> things stay in
> >> the apps, and technical facilitation and
> interfacing lives
> >> in the framework. If we want to change that, it
> would be a
> >> big change, and you can certainly expect some
> disagreement.
> > 
> > This is the same thing I tried to suggest. The
> framework should include only those things needed to get an
> application to run, and not include application code.
> > 
> > From my perspective, sending and receiving emails is
> an application. It could run on top of the framework, and
> other applications could utilize it.
> 
> Aren't most programs that run on top of an operating system
> applications? How does that help us draw the line?
> 
> Also if email is a higher level function that should only
> be supported on an application level, what about MCA rules
> and email libraries in the Java API? Aren't those both
> pretty low level things?
> 
> Doesn't that muddy the distinction more than clarify it?

I'm sure everyone has their own mental picture of where that line is drawn.

In my mind, I picture the framework composed of only the entity engine, service engine, the rendering engine, the security framework, and the webtools and example applications.

Email could be a component that runs on top of the framework and that other components use.

In my mind that is a clear distinction. There is no doubt others won't see it that way.

-Adrian



      

Re: Moving securityext to the framework

[David E Jones <de...@me.com>]

On Jan 3, 2010, at 2:04 PM, Adrian Crum wrote:

> --- On Sun, 1/3/10, David E Jones <de...@me.com> wrote:
>> One way or another if we're moving things around,
>> especially moving higher level stuff into the framework,
>> then we should definitely discuss it first and even try to
>> reach a consensus around it.
>> 
>> For example, one specific idea might be to move some of the
>> email stuff from content to the framework somewhere. Sending
>> and receiving emails is pretty low-level, though that
>> doesn't mean we'd want to move all of it as the
>> CommunicationEvent stuff is definitely higher level and ties
>> to many many other things in the system, and that's a much
>> harder line to draw.
>> 
>> For the most part the dividing line between framework and
>> the base applications is that business-driven things stay in
>> the apps, and technical facilitation and interfacing lives
>> in the framework. If we want to change that, it would be a
>> big change, and you can certainly expect some disagreement.
> 
> This is the same thing I tried to suggest. The framework should include only those things needed to get an application to run, and not include application code.
> 
> From my perspective, sending and receiving emails is an application. It could run on top of the framework, and other applications could utilize it.

Aren't most programs that run on top of an operating system applications? How does that help us draw the line?

Also if email is a higher level function that should only be supported on an application level, what about MCA rules and email libraries in the Java API? Aren't those both pretty low level things?

Doesn't that muddy the distinction more than clarify it?

-David

Re: Moving securityext to the framework

[Adrian Crum <ad...@yahoo.com>]

--- On Sun, 1/3/10, David E Jones <de...@me.com> wrote:
> One way or another if we're moving things around,
> especially moving higher level stuff into the framework,
> then we should definitely discuss it first and even try to
> reach a consensus around it.
> 
> For example, one specific idea might be to move some of the
> email stuff from content to the framework somewhere. Sending
> and receiving emails is pretty low-level, though that
> doesn't mean we'd want to move all of it as the
> CommunicationEvent stuff is definitely higher level and ties
> to many many other things in the system, and that's a much
> harder line to draw.
> 
> For the most part the dividing line between framework and
> the base applications is that business-driven things stay in
> the apps, and technical facilitation and interfacing lives
> in the framework. If we want to change that, it would be a
> big change, and you can certainly expect some disagreement.

This is the same thing I tried to suggest. The framework should include only those things needed to get an application to run, and not include application code.

>From my perspective, sending and receiving emails is an application. It could run on top of the framework, and other applications could utilize it.

-Adrian



      

Re: Moving securityext to the framework

[David E Jones <de...@me.com>]

On Jan 3, 2010, at 3:53 AM, Bruno Busco wrote:

> When I sayd "at least me" I should have said "To implement the
> framework-only distribution end-user requirements here
> http://cwiki.apache.org/OFBIZ/framework-only-distribution.html"
> We should agree or change what is written there and then work to implement it.

Please keep in mind that is just your document. There is no such thing as implicit agreement, and if there are disagreements on the mailing list IMO that is just as valid as someone going in and changing your document (and most people would probably consider it less rude too, which is maybe why no one has made changes there).

BTW, looking through those... where are the CMS related requirements? What sorts of business activities drive these requirements?

Actually, to be more accurate, I wouldn't call any of the things you listed there requirements, they all look like designs to me, ie solutions to the problems rather than the problems themselves.

> The framework-only work should of course generate two workproducts:
> - A standalone framework implementing the requirements
> - A set of additional components, each with its declared dependencies,
> that can be plugged in the framework-only installation.
> 
> For my next project all I would like to do is to select the newly
> needed components and plug them in the framework-only.
> 
> The sets of components framework+party+content+commonext should give
> us a basic configuration that, from the user POV should be similar to
> a CMS system but powered by OFBiz.

And what about those who not only don't care either way about CMS, but really don't want to bother with CMS in the system? One way or another you're sure to get complaints...

> This CMS configuration, IMO, should have the greatest number of
> potential users and, for this reason, should receive a greater
> contribution from a greater community.

That is an interesting opinion, and it's great that you have been looking into this. Could you share what you have based this opinion on, it might be enlightening to others too.

> This configuration is also what we would need to run the OFBiz web
> site itself (if we are still interested in getting this up and
> running).
> 
> Of course, as you say, there are some things in the selected
> components (framework, party, content, commonext) that are not
> required. These parts are, for sure, the ones that do not let the
> database to be even created because depends on other components. There
> are entities that should be moved away from party as the complete
> org.ofbiz.party.agreement and org.ofbiz.party.need sets, some other
> that should be extended in other components.

Again, that's based on your designs which are based on requirements you haven't shared yet.

> So coming to your question: "what should we change in how we're doing things?"
> May be nothing. Just discuss/agree on the requirements for the
> framework-only and then start working on a branch.

That sounds like a change to me...

One way or another if we're moving things around, especially moving higher level stuff into the framework, then we should definitely discuss it first and even try to reach a consensus around it.

For example, one specific idea might be to move some of the email stuff from content to the framework somewhere. Sending and receiving emails is pretty low-level, though that doesn't mean we'd want to move all of it as the CommunicationEvent stuff is definitely higher level and ties to many many other things in the system, and that's a much harder line to draw.

For the most part the dividing line between framework and the base applications is that business-driven things stay in the apps, and technical facilitation and interfacing lives in the framework. If we want to change that, it would be a big change, and you can certainly expect some disagreement.

On the other hand, you can certainly work on decoupling in the base applications in order to isolate the parts that you want to. They'll stay in the applications directory, but you can certainly make changes to make things run fine in spite of deleting or disabling other components.

-David


> 2010/1/2 David E Jones <de...@me.com>:
>> 
>> On Jan 2, 2010, at 2:42 PM, Bruno Busco wrote:
>> 
>>>> 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.
>>> 
>>> The more we discuss about this the more I get convinced that what we
>>> (or at least me) intend for framework-only distribution should be
>>> better named "OFBiz-core".
>>> The OFBiz-core could consist of framework + party + content + commonext.
>>> 
>>> A distribution with these components set up is somewhat similar to
>>> what I mean for a framework where developer can start building its
>>> office automation application without the necessity to disable
>>> anything but having all the power of the framework and the "core"
>>> applications.
>> 
>> Your "at least me" comment is right on. Consider that what you want, at least right now, is framework + party + content + commonext. Do you think that will be the same for your next project? Do you think that this is the same for a majority of current and prospective users of OFBiz?
>> 
>> I'd be willing to bet a good deal of money that this level of granularity is not adequate to describe what you actually need/want, and that within each of the parts you listed (framework, party, content, commonext) there are dozens or hundreds of more specific things that you either want or don't want.
>> 
>> Now consider that with many thousands of such things that will be wanted or not wanted, there are an incredible number of combinations of these things. Each combination is a potential "core" packaging of OFBiz.
>> 
>> So, the question is what will be of most use to the largest number of users? That question a good guiding thought, and because of the community nature of this project it will of course be tempered by what contributors (committers or not) actually decide is important to them.
>> 
>> Based on that, what should we change in how we're doing things?
>> 
>> -David
>> 
>> 

Re: Moving securityext to the framework

[Bruno Busco <br...@gmail.com>]

When I sayd "at least me" I should have said "To implement the
framework-only distribution end-user requirements here
http://cwiki.apache.org/OFBIZ/framework-only-distribution.html"
We should agree or change what is written there and then work to implement it.

The framework-only work should of course generate two workproducts:
- A standalone framework implementing the requirements
- A set of additional components, each with its declared dependencies,
that can be plugged in the framework-only installation.

For my next project all I would like to do is to select the newly
needed components and plug them in the framework-only.

The sets of components framework+party+content+commonext should give
us a basic configuration that, from the user POV should be similar to
a CMS system but powered by OFBiz.
This CMS configuration, IMO, should have the greatest number of
potential users and, for this reason, should receive a greater
contribution from a greater community.

This configuration is also what we would need to run the OFBiz web
site itself (if we are still interested in getting this up and
running).

Of course, as you say, there are some things in the selected
components (framework, party, content, commonext) that are not
required. These parts are, for sure, the ones that do not let the
database to be even created because depends on other components. There
are entities that should be moved away from party as the complete
org.ofbiz.party.agreement and org.ofbiz.party.need sets, some other
that should be extended in other components.

So coming to your question: "what should we change in how we're doing things?"
May be nothing. Just discuss/agree on the requirements for the
framework-only and then start working on a branch.

-Bruno

2010/1/2 David E Jones <de...@me.com>:
>
> On Jan 2, 2010, at 2:42 PM, Bruno Busco wrote:
>
>>> 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.
>>
>> The more we discuss about this the more I get convinced that what we
>> (or at least me) intend for framework-only distribution should be
>> better named "OFBiz-core".
>> The OFBiz-core could consist of framework + party + content + commonext.
>>
>> A distribution with these components set up is somewhat similar to
>> what I mean for a framework where developer can start building its
>> office automation application without the necessity to disable
>> anything but having all the power of the framework and the "core"
>> applications.
>
> Your "at least me" comment is right on. Consider that what you want, at least right now, is framework + party + content + commonext. Do you think that will be the same for your next project? Do you think that this is the same for a majority of current and prospective users of OFBiz?
>
> I'd be willing to bet a good deal of money that this level of granularity is not adequate to describe what you actually need/want, and that within each of the parts you listed (framework, party, content, commonext) there are dozens or hundreds of more specific things that you either want or don't want.
>
> Now consider that with many thousands of such things that will be wanted or not wanted, there are an incredible number of combinations of these things. Each combination is a potential "core" packaging of OFBiz.
>
> So, the question is what will be of most use to the largest number of users? That question a good guiding thought, and because of the community nature of this project it will of course be tempered by what contributors (committers or not) actually decide is important to them.
>
> Based on that, what should we change in how we're doing things?
>
> -David
>
>

Re: Moving securityext to the framework

[Christopher Snow <sn...@snowconsulting.co.uk>]

David E Jones wrote:
> On Jan 2, 2010, at 2:42 PM, Bruno Busco wrote:
>
>   
>>> 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.
>>>       
>> The more we discuss about this the more I get convinced that what we
>> (or at least me) intend for framework-only distribution should be
>> better named "OFBiz-core".
>> The OFBiz-core could consist of framework + party + content + commonext.
>>
>> A distribution with these components set up is somewhat similar to
>> what I mean for a framework where developer can start building its
>> office automation application without the necessity to disable
>> anything but having all the power of the framework and the "core"
>> applications.
>>     
>
> Your "at least me" comment is right on. Consider that what you want, at least right now, is framework + party + content + commonext. Do you think that will be the same for your next project? Do you think that this is the same for a majority of current and prospective users of OFBiz?
>
> I'd be willing to bet a good deal of money that this level of granularity is not adequate to describe what you actually need/want, and that within each of the parts you listed (framework, party, content, commonext) there are dozens or hundreds of more specific things that you either want or don't want.
>
> Now consider that with many thousands of such things that will be wanted or not wanted, there are an incredible number of combinations of these things. Each combination is a potential "core" packaging of OFBiz.
>
> So, the question is what will be of most use to the largest number of users? That question a good guiding thought, and because of the community nature of this project it will of course be tempered by what contributors (committers or not) actually decide is important to them.
>
> Based on that, what should we change in how we're doing things?
>
> -David
>
>   
David,

Your view ties in very much with my recent experiences.  My last project 
just required framework + party, whereas my current project requires 
framework + party + workeffort.

This has made me question whether it is practical to separate the 
components as you will never know what combination you may need. 

Could the problem be approached from a different angle - if unwanted 
components are commented out and there are dependency issues, rather 
than missing dependencies causing fatal startup errors at startup, how 
about a warning being issued instead?

Cheers,

Chris

Re: Moving securityext to the framework

[David E Jones <de...@me.com>]

On Jan 2, 2010, at 2:42 PM, Bruno Busco wrote:

>> 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.
> 
> The more we discuss about this the more I get convinced that what we
> (or at least me) intend for framework-only distribution should be
> better named "OFBiz-core".
> The OFBiz-core could consist of framework + party + content + commonext.
> 
> A distribution with these components set up is somewhat similar to
> what I mean for a framework where developer can start building its
> office automation application without the necessity to disable
> anything but having all the power of the framework and the "core"
> applications.

Your "at least me" comment is right on. Consider that what you want, at least right now, is framework + party + content + commonext. Do you think that will be the same for your next project? Do you think that this is the same for a majority of current and prospective users of OFBiz?

I'd be willing to bet a good deal of money that this level of granularity is not adequate to describe what you actually need/want, and that within each of the parts you listed (framework, party, content, commonext) there are dozens or hundreds of more specific things that you either want or don't want.

Now consider that with many thousands of such things that will be wanted or not wanted, there are an incredible number of combinations of these things. Each combination is a potential "core" packaging of OFBiz.

So, the question is what will be of most use to the largest number of users? That question a good guiding thought, and because of the community nature of this project it will of course be tempered by what contributors (committers or not) actually decide is important to them.

Based on that, what should we change in how we're doing things?

-David

Re: Moving securityext to the framework

[Tim Ruppert <ti...@hotwaxmedia.com>]

Those of us with strong Unix backgounds really don't want to see anything named "core" - so I'd say let's look for some other name.  What you're pushing for Bruno - is much needed and could be a great enhancement to the usage of OFBiz.  Anything that'll make it easier for people to build - non-eCommerce related applications without having to disable anything is a huge win in my book.

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

o:801.649.6594
f:801.649.6595

On Jan 2, 2010, at 1:42 PM, Bruno Busco wrote:

>> 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.
> 
> The more we discuss about this the more I get convinced that what we
> (or at least me) intend for framework-only distribution should be
> better named "OFBiz-core".
> The OFBiz-core could consist of framework + party + content + commonext.
> 
> A distribution with these components set up is somewhat similar to
> what I mean for a framework where developer can start building its
> office automation application without the necessity to disable
> anything but having all the power of the framework and the "core"
> applications.
> 
> -Bruno

Re: Moving securityext to the framework

[Bruno Busco <br...@gmail.com>]

> 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.

The more we discuss about this the more I get convinced that what we
(or at least me) intend for framework-only distribution should be
better named "OFBiz-core".
The OFBiz-core could consist of framework + party + content + commonext.

A distribution with these components set up is somewhat similar to
what I mean for a framework where developer can start building its
office automation application without the necessity to disable
anything but having all the power of the framework and the "core"
applications.

-Bruno

Re: Moving securityext to the framework

[Tim Ruppert <ti...@hotwaxmedia.com>]

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?

Re: Moving securityext to the framework

[Adam Heath <do...@brainfood.com>]

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?