On 16 Oct 2015, at 08:47, Ron Wheeler <rwhee...@artifact-software.com> wrote:
Before we start to decide who can access code, we need to decide on a roadmap
for the new framework.
How different will the API be from the current framework in each of the areas
that the framework will offer services?
How modular will it be?
Foundation identifies
- Core with 3 main areas of functionality. Can they be separated into separate
projects with clean interfaces? are there more projects such as authentication,
persistence, logging and audit (see below) that are shared across the
Foundation Core high level features.
- Script
- Imex
- Connect - seems to a number of projects here that could be tackled separately.
Is this it?
Will there be an application isolation layer that will support OFBiz's current
interaction with the Framework. This should also be a separate project where
OFBiz knowledge is really valuable.
What will go underneath the covers? Spring-Boot , Spring JPA, Hibernate, etc.
How many containers will be supported. Tomcat, Jetty, Glassfish, Spring-Boot.
How many persistence options will be supported? SQL, No-SQL
How many authentication services will be supported - internal, LDAP, Oauth,
Google, LinkedIn, Facebook.
What administration functions will be offered? How? JConsole, REST,
browser/mobile apps.
How delivered? Installer, Docker image, VM image,
What demo apps?
What test framework(s)? Test Applications.
What would be a reasonable set of functionality to be released in version 1.0?
Minimum useful framework.
How many people would it take to do this in a reasonable timeframe?
Ron
On 16/10/2015 3:41 AM, Pierre Smits wrote:
On Fri, Oct 16, 2015 at 5:31 AM, David E. Jones <d...@me.com> wrote:
On 15 Oct 2015, at 07:58, Adrian Crum <
adrian.c...@sandglass-software.com> wrote:
Keep in mind that much of David's code in OFBiz has been rewritten. So
yes, we CAN do a better job than him.
I think there’s a name for this logical fallacy…
And this could also be called a logical fallacy. But let us not make it
into a pissing contest again, like we had in the past regarding the
opposing viewpoints on this.
Also keep in mind that Moqui duplicates some of the problems I listed -
so by using Moqui, we keep the same problems instead of fixing them.
Could you be more specific, other than the type conversion stuff you
mentioned many years ago (which I fully disagree with)?
This is not about who is right or wrong, but where the community wants to
go.
I understand the reluctance of the community, because the impact will be
huge. When looking at the data in OpenHub I see OFBiz having an estimate
effort spend of 519 person years vs 6 for the combined
Moqui-Mantle-HiveMindPM-PopCommerce suite. And one of the reasons behind it
is simple: Many more have worked on OFBiz (from day 1) than on the Moqui
suite. One could even argue that both directions took the same number of
years in duration to get where they are now. Without all the experiences
regarding the OFBiz product there couldn't have been an evolution called
the Moqui suite.
Coming back to opting for a new direction, as Scott has stated we can have
this in a separate code repository (subproject, like many other Apache
projects do their work) even combined with a new JIRA an Wiki under the
umbrella of the OFBiz project. Based on the comments provided, this seems
like a logical choice to ensure that adopters of the current solution will
keep the support of the community while at the same time ensuring
containment of the new approach.
But these are mere technical, supportive aspects. The more important issue
is what this new solution will encompass. There are talks of a rewrite,
which sounds like reinvention of the wheel. But I guess it is not like
that. Yet, taking decisions based on a few one-pagers (e.g.
http://www.sandglass-software.com/products/sandglass/documents/Foundation_Brochure.pdf)
are seldom done. Maybe it works for a single person, but I doubt it will
make a community fly.
Whether fix or rewrite, choices will be made regarding the supporting 3rd
party libraries/solutions and the community needs to understand the impact
to get behind it. So before we embark on the coding trip, let us get into
trying to define a bit more what the new solution will encompass and get
consensus on that.
Another issue regarding getting the community behind behind this new effort
is this: 'restrict access to the new code'. I guess this meant restrict
write access. Though understandable from a avoidance of dilution/scope
creep point of view, I see this as a wrong direction. This 'proposed'
exclusion of contributors of the kind will bring us back to where this
project came from: discrimination and favouritism. I even doubt that this
is possible under the current principles of the ASF.
Given that this is an enormous undertaking, we need to get as many on board
as possible. Not only to ensure that the decisions (at each level) will get
consensus, but also the ensure that every aspect down the line will get
addressed (e.g. documentation, test definitions, marketing/promotions, etc)
in order to get this kite flying.
Best regards,
Pierre Smits
*OFBiz Extensions Marketplace*
http://oem.ofbizci.net/oci-2/
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
