ofbiz-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Busco <bruno.bu...@gmail.com>
Subject Re: Moving securityext to the framework
Date Mon, 04 Jan 2010 22:07:32 GMT
Hi David,

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

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


View raw message