Le 22/03/2015 08:46, Gavin Mabie a écrit :
Hi Pierre
If you use a 3rd party crm solution you wouldn't use the sfa application.
If you use a 3rd party HRM solution, you wouldn't use humanres.
Following this line of thinking, let's consider this ridiculous
hypothetical scenario:
- 3rd Party Accounting App;
- 3rd Party HR;
- 3rd Party SFA;
- 3rd Party Catalog Management;
- 3rd Party CMS;
- etc
What would be Ofbiz's Value Proposition in this case? There are core
applications that users expect to find in an ERP OOTB.
Good point Gavin :D
Jacques
Gavin
On Sat, Mar 21, 2015 at 6:02 PM, Pierre Smits <pierre.sm...@gmail.com>
wrote:
How we have it now is a viewpoint. A viewpoint that you may not or may
agree with.
If you don't have anything to do with manufacturing or fixed assets or
workefforts or calendars, because you're operating a (fairly) simple retail
shop and use OFBiz, you currently don't have the option disable these
without developer work.
If you use a 3rd party crm solution you wouldn't use the sfa application.
If you use a 3rd party HRM solution, you wouldn't use humanres.
In other threads it has been said or implied that OFBiz isn't a single
vertical solution. The total package reflects that. But we have to offer
more optionality. Manufacturing is not core to all. SFA is not core to all.
Humanres is not core to all. Having these in the applications folder
implies that is not optional.
Best regards,
Pierre Smits
*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com
On Sat, Mar 21, 2015 at 4:28 PM, Gavin Mabie <kwikst...@gmail.com> wrote:
The passport component is an optional. So is the e-commerce component
and
almost everything else is.
Not sure about this.
Where apps should be placed is matter of viewpoint. And we have
viewpoints
aplenty. Some regard e-commerce to be a core (framework + application
stack) extension
Should it be a matter of viewpoint? Clearly, there must be a standard
approach. Ofbiz is an ERP system first and foremost and as such should
have the typical ERP functionalities as applications (as it does now).
*Application Stack*: Accounting, Manufacturing and or Distribution, CRM,
HR
and Payroll, Inventory, Marketing and Sales etc. should be under the
application stack as a minimum. These aren't optional.
*Technology Stack*: Technologies without which these cannot be
implemented
go under the Framework/Technology stack.
*Special Purpose*: Project Management, e-Commerce, Hospitality, Brewing?
IMHO special purpose should not be used for third party
technologies/integration.
*Tools/Plugins*: BIRT, DotNet, eBay, OAuth2, Lucene, Solr etc.
Regards
Gavin
On Sat, Mar 21, 2015 at 4:58 PM, Pierre Smits <pierre.sm...@gmail.com>
wrote:
The passport component is an optional. So is the e-commerce component
and
almost everything else is. There are some dependencies from components
in
the applications and framework stacks to specifics in the special
purpose
stack (birt, ldap - when applied and lucene?). But those are few, and
we
can live with as these few enhance the functionality of the lower level
components and thus user experience.
Where apps should be placed is matter of viewpoint. And we have
viewpoints
aplenty. Some regard e-commerce to be a core (framework + application
stack) extension. In its current state it is part of a vertical to.
Retail
in particular, as it isn't a complete front-end solution for B2B
(multiple
verticals), B2G (ambiguous vertical) and marketplaces (again multiple
verticals). If you don't do manufacturing, shouldn't the same named
component not be an optional and thus not in applications. If you do
HRM
but don't use the humanres component, shouldn't that component be
better
of
in the special purpose stack stack without being referenced in the
component-load.xml file.
The special purpose stack is a good place for any application/component
but
the base registers in the applications stack. We should consider to
make
as
many as possible optional in that stack, by removing its reference in
the
aforementioned component-load.xml. As it would surely reduce server
load.
And we would give adopters a choice. Not only before adopting, but also
during the lifespan.
Best regards,
Pierre Smits
*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com
On Sat, Mar 21, 2015 at 3:26 PM, Gavin Mabie <kwikst...@gmail.com>
wrote:
Hi Jacques
My concern is about the proper use of the specialpurpose folder.
Birt
is
IMO not a special purpose application, but rather a tool that can be
used
across applications, and so is Lucene. Additionally, these are
optional
functionalities and therefore non-core. My thinking is that if
something
is
optional, non-core and not a special implementation of the framework,
then
it should go into this folder. So I agree that BIRT and Lucene are
candidates for inclusion in this folder (my knowledge of OAGIS is
sketchy
at best). BTW I'm not to sure about calling it "Tools". "Plugins"
is
the
term that is widely used for this sort of thing.
Gavin
On Sat, Mar 21, 2015 at 3:19 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:
Hi Gavin,
Interesting, so you would suggest to create a new tools folder at
the
same
level of dependency than specialpurpose and to add this new
passport
Component to it.
Then we could also move ldap. I thought about jetty also, but I
will
rather open a new thread for that since we decided to discuss to
move
it
to
Attic
Do you (everybody ;)) see other components which could me moved to
this
new tools folder? Maybe bi, birt, oagis, even lucene?
Jacques
Le 21/03/2015 08:32, Gavin Mabie a écrit :
Hi Jacques
I know that there's been quite a bit of discussion about this and
I
don't
want to rehash stuff that's been dealt with and agreed upon in the
past
-
but is this really a special purpose component? It appears to be a
tool/utility. Special purpose components should really be for
special
applications of the Ofbiz Framework, i.e. applying the framework
in
a
special user or industry way. So for example, ecommerce is a
special
purpose component - it implements ofbiz in a user specific way.
Ofiz
Healh
Care/Communications/Hospitality/Government/ etc would be industry
special
purpose components.
Gavin
On Sat, Mar 21, 2015 at 9:11 AM, Pierre Smits <
pierre.sm...@gmail.com
wrote:
Might indeed be interesting for a increase in the consumer area
and
not
the
back end (but with market places and that tendency might shift).
It seems there are some security concerns. See here:
https://en.wikipedia.org/wiki/OAuth#OAuth_2.0. Yet the list of
providers
is
impressive.
And I have look over the issue and wonder if we really need the
gson
and
paypal jars.
Best regards,
Pierre Smits
*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com
On Sat, Mar 21, 2015 at 5:37 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:
Hi,
Shi Jinghai contributed a Passport Component for OAuth2 at
https://issues.apache.org/jira/browse/OFBIZ-6135
It seems to me an interesting specialpurpose component to add. I
will
do
so if nobody is against.
Jacques
