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
