You are viewing a plain text version of this content. The canonical link for it is here.

Posted to user@ofbiz.apache.org by Philip Laing <ph...@ascconsultants.com.au> on 2007/10/02 02:06:12 UTC

Download SVN Repository

Hi Fellas
I am preparing a Linux box with OFBiz + PostgreSQL ... I have had Compiere
and OpenBravo installed on my windows server boxes and have investigated
TinyERP however OFBiz seems to fit in better with my business model which
largely consists of virtual warehousing and drop ship ecommerce.  This is my
first posting in this forum so excuse me if I have missed any protocol or my
questions seem simplistic. So here we go

1. How do I download from the required SVN repositories using windows?
2. Search the list archives for threads other than scrolling through one by
one?

Thanks in advance
Wikitec

Re: Linux distro?

Posted by Jonathon -- Improov <jo...@improov.com>.

Er... correction. I think my clients needed to use SDK 1.4 . And there was no support for 64-bit 
AMD (or 64-bit anything, can't recall).

There should be SDKs for 64-bit AMD and Intel from SDK 1.5 and above.

Jonathon

Jonathon -- Improov wrote:
> For 64-bit AMD? That'll be good. Last I saw, there were only versions 
> for 64-bit Intel.
> 
> Jonathon
> 
> clearchris wrote:
>> Sun did release a 64 bit version of java for linux, and I haven't
>> encountered any issues with it and ofbiz, other than being 
>> incompatible with
>> the 32bit pos hardware drivers.
>>
>> C
>>
>> -----Original Message-----
>> From: Jonathon -- Improov [mailto:jonw@improov.com] Sent: Tuesday, 
>> October 02, 2007 9:27 PM
>> To: user@ofbiz.apache.org
>> Subject: Re: Linux distro?
>>
>> A couple of clients I have use 64-bit AMD machines. I recall there 
>> weren't
>> any official Sun SDKs supporting those machines. My clients were 
>> forced to use some other non-Sun
>> SDKs. Not good. Lots of bizarre issues.
>>
>> As for 64-bit gotchas, I wouldn't be surprised. Newer hardwares often 
>> have
>> new problems. I try to go with mainstream models. Cluster up a few 
>> mainstream workhorses if we need
>> more power.
>>
>> Jonathon
>>
>> Skip wrote:
>>> BJ
>>>
>>> Thats a good idea, I would be particularly happy to hear about 64 bit
>>> gotchas.  I seem to remember hearing about memory > 2gigs causing a
>> problem
>>> with multiple CPUs and > 2gigs of memory or some such.
>>>
>>> Skip
>>>
>>> -----Original Message-----
>>> From: BJ Freeman [mailto:bjfree@free-man.net]
>>> Sent: Tuesday, October 02, 2007 9:30 AM
>>> To: user@ofbiz.apache.org
>>> Subject: Re: Linux distro?
>>>
>>>
>>> The only condsideration is if the distro you your plan to use supports
>>> Sun SDK package.
>>> as long as you have 1.5 or better on you box then you ok.
>>> Fedora installs the opensource SDK and yum does not work to get the sun
>> SDK.
>>> Maybe we should put a doc file up that everyone can put what distro they
>>> have tried and if they were sucessful or not.
>>>
>>>
>>>
>>> clearchris sent the following on 10/2/2007 8:41 AM:
>>>> I plan on running Gentoo, though many disagree with that choice.
>>>>
>>>> http://linux.slashdot.org/linux/07/01/28/2227232.shtml
>>>>
>>>> I find that using the stable (non ~) branch with occasional upgrades to
>>> ~x86
>>>> (unstable) programs runs quite well.  It's the best of both worlds 
>>>> IMHO,
>>> you
>>>> can get the stable software and you can get the newer fixes that you
>>>> inevitably will need.  Best of all, it provides a nice framework for
>>>> managing that complexity.
>>>>
>>>> If you plan on using the POS application under linux, I'd highly 
>>>> suggest
>>>> using a 32 bit distribution, even if you have a 64 bit processor.  Most
>>>> (nearly all it seems) JavaPOS drivers have a native binary component 
>>>> that
>>> is
>>>> 32 bit.  While AMD processors can run 32 bit code natively, the binary
>>>> drivers require 32 bit system libraries, etc, which can get a bit
>>>> interesting to set up.
>>>>
>>>> My 2c.
>>>>
>>>> Chris
>>>>
>>>> -----Original Message-----
>>>> From: Philip Laing [mailto:philip.laing@ascconsultants.com.au]
>>>> Sent: Tuesday, October 02, 2007 12:05 AM
>>>> To: user@ofbiz.apache.org
>>>> Subject: Linux distro?
>>>>
>>>> Thanks skip - just looking at a review on CentOS at the moment.  Looks
>>>> fairly impressive for server stability
>>>>
>>>> cheers
>>>>
>>>> Phil
>>>>
>>>>> -----Original Message-----
>>>>> From: skip@theDevers [mailto:skip@thedevers.org]
>>>>> Sent: Tuesday, 2 October 2007 1:59 PM
>>>>> To: user@ofbiz.apache.org
>>>>> Subject: RE: Download SVN Repository ... Linux distro?
>>>>>
>>>>> Instead of Fedora Core, give a look at CentOS.  Its a good deal more
>>>>> stable.
>>>>> I have had lots of weird problems with Fedora in the past (usually 
>>>>> fixed
>>>>> within a few weeks, but still a pain when it happens).
>>>>>
>>>>> Skip
>>>>>
>>>>> -----Original Message-----
>>>>> From: Philip Laing [mailto:philip.laing@ascconsultants.com.au]
>>>>> Sent: Monday, October 01, 2007 6:01 PM
>>>>> To: user@ofbiz.apache.org
>>>>> Subject: RE: Download SVN Repository ... Linux distro?
>>>>>
>>>>>
>>>>> Thanks BJ ... Now what distro would be more suited these days?  I am
>>>>> looking
>>>>> at Fedora or Ununtu ... some may have preferences for viable reasons
>>>>>
>>>>> Thanks again ... quick reply to my question ... I think I am going to
>>> like
>>>>> setting up and configuring OFBiz
>>>>>
>>>>> Phil
>>>>>
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: BJ Freeman [mailto:bjfree@free-man.net]
>>>>>> Sent: Tuesday, 2 October 2007 10:29 AM
>>>>>> To: user@ofbiz.apache.org
>>>>>> Subject: Re: Download SVN Repository
>>>>>>
>>>>>> first read
>>>>>>
>>> http://docs.ofbiz.org/display/OFBTECH/Apache+OFBiz+Technical+Production+Se 
>>>
>>>>>> tup+Guide\
>>>>>> http://docs.ofbiz.org/display/OFBIZ/How+to+run+OFBiz+as+a+Service
>>>>>> may help.
>>>>>> then on your linux box
>>>>>> load svn
>>>>>> some use wget
>>>>>> then you can use the svn commands to load ofbiz.
>>>>>> http://docs.ofbiz.org/display/OFBADMIN/Demo+and+Test+Setup+Guide
>>>>>>
>>>>>> Philip Laing sent the following on 10/1/2007 5:06 PM:
>>>>>>> Hi Fellas
>>>>>>> I am preparing a Linux box with OFBiz + PostgreSQL ... I have had
>>>>>> Compiere
>>>>>>> and OpenBravo installed on my windows server boxes and have
>>>>> investigated
>>>>>>> TinyERP however OFBiz seems to fit in better with my business model
>>>>>> which
>>>>>>> largely consists of virtual warehousing and drop ship ecommerce.  
>>>>>>> This
>>>>>> is my
>>>>>>> first posting in this forum so excuse me if I have missed any 
>>>>>>> protocol
>>>>>> or my
>>>>>>> questions seem simplistic. So here we go
>>>>>>>
>>>>>>> 1. How do I download from the required SVN repositories using 
>>>>>>> windows?
>>>>>>> 2. Search the list archives for threads other than scrolling through
>>>>> one
>>>>>> by
>>>>>>> one?
>>>>>>>
>>>>>>> Thanks in advance
>>>>>>> Wikitec
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
> 
>

RE: Linux distro?

Posted by "skip@theDevers" <sk...@thedevers.org>.

I have found the IBM sdk to be superior to Suns, although I haven't used it
on a 64 bit platform.  Its memory management is better and it seems more
stable in my testing.  If you have memory leak problems, it has great tools
to track them down.

Skip

-----Original Message-----
From: Jonathon -- Improov [mailto:jonw@improov.com]
Sent: Tuesday, October 02, 2007 8:56 PM
To: user@ofbiz.apache.org
Subject: Re: Linux distro?


For 64-bit AMD? That'll be good. Last I saw, there were only versions for
64-bit Intel.

Jonathon

clearchris wrote:
> Sun did release a 64 bit version of java for linux, and I haven't
> encountered any issues with it and ofbiz, other than being incompatible
with
> the 32bit pos hardware drivers.
>
> C
>
> -----Original Message-----
> From: Jonathon -- Improov [mailto:jonw@improov.com]
> Sent: Tuesday, October 02, 2007 9:27 PM
> To: user@ofbiz.apache.org
> Subject: Re: Linux distro?
>
> A couple of clients I have use 64-bit AMD machines. I recall there weren't
> any official Sun SDKs
> supporting those machines. My clients were forced to use some other
non-Sun
> SDKs. Not good. Lots
> of bizarre issues.
>
> As for 64-bit gotchas, I wouldn't be surprised. Newer hardwares often have
> new problems. I try to
> go with mainstream models. Cluster up a few mainstream workhorses if we
need
> more power.
>
> Jonathon
>
> Skip wrote:
>> BJ
>>
>> Thats a good idea, I would be particularly happy to hear about 64 bit
>> gotchas.  I seem to remember hearing about memory > 2gigs causing a
> problem
>> with multiple CPUs and > 2gigs of memory or some such.
>>
>> Skip
>>
>> -----Original Message-----
>> From: BJ Freeman [mailto:bjfree@free-man.net]
>> Sent: Tuesday, October 02, 2007 9:30 AM
>> To: user@ofbiz.apache.org
>> Subject: Re: Linux distro?
>>
>>
>> The only condsideration is if the distro you your plan to use supports
>> Sun SDK package.
>> as long as you have 1.5 or better on you box then you ok.
>> Fedora installs the opensource SDK and yum does not work to get the sun
> SDK.
>> Maybe we should put a doc file up that everyone can put what distro they
>> have tried and if they were sucessful or not.
>>
>>
>>
>> clearchris sent the following on 10/2/2007 8:41 AM:
>>> I plan on running Gentoo, though many disagree with that choice.
>>>
>>> http://linux.slashdot.org/linux/07/01/28/2227232.shtml
>>>
>>> I find that using the stable (non ~) branch with occasional upgrades to
>> ~x86
>>> (unstable) programs runs quite well.  It's the best of both worlds IMHO,
>> you
>>> can get the stable software and you can get the newer fixes that you
>>> inevitably will need.  Best of all, it provides a nice framework for
>>> managing that complexity.
>>>
>>> If you plan on using the POS application under linux, I'd highly suggest
>>> using a 32 bit distribution, even if you have a 64 bit processor.  Most
>>> (nearly all it seems) JavaPOS drivers have a native binary component
that
>> is
>>> 32 bit.  While AMD processors can run 32 bit code natively, the binary
>>> drivers require 32 bit system libraries, etc, which can get a bit
>>> interesting to set up.
>>>
>>> My 2c.
>>>
>>> Chris
>>>
>>> -----Original Message-----
>>> From: Philip Laing [mailto:philip.laing@ascconsultants.com.au]
>>> Sent: Tuesday, October 02, 2007 12:05 AM
>>> To: user@ofbiz.apache.org
>>> Subject: Linux distro?
>>>
>>> Thanks skip - just looking at a review on CentOS at the moment.  Looks
>>> fairly impressive for server stability
>>>
>>> cheers
>>>
>>> Phil
>>>
>>>> -----Original Message-----
>>>> From: skip@theDevers [mailto:skip@thedevers.org]
>>>> Sent: Tuesday, 2 October 2007 1:59 PM
>>>> To: user@ofbiz.apache.org
>>>> Subject: RE: Download SVN Repository ... Linux distro?
>>>>
>>>> Instead of Fedora Core, give a look at CentOS.  Its a good deal more
>>>> stable.
>>>> I have had lots of weird problems with Fedora in the past (usually
fixed
>>>> within a few weeks, but still a pain when it happens).
>>>>
>>>> Skip
>>>>
>>>> -----Original Message-----
>>>> From: Philip Laing [mailto:philip.laing@ascconsultants.com.au]
>>>> Sent: Monday, October 01, 2007 6:01 PM
>>>> To: user@ofbiz.apache.org
>>>> Subject: RE: Download SVN Repository ... Linux distro?
>>>>
>>>>
>>>> Thanks BJ ... Now what distro would be more suited these days?  I am
>>>> looking
>>>> at Fedora or Ununtu ... some may have preferences for viable reasons
>>>>
>>>> Thanks again ... quick reply to my question ... I think I am going to
>> like
>>>> setting up and configuring OFBiz
>>>>
>>>> Phil
>>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: BJ Freeman [mailto:bjfree@free-man.net]
>>>>> Sent: Tuesday, 2 October 2007 10:29 AM
>>>>> To: user@ofbiz.apache.org
>>>>> Subject: Re: Download SVN Repository
>>>>>
>>>>> first read
>>>>>
>>
http://docs.ofbiz.org/display/OFBTECH/Apache+OFBiz+Technical+Production+Se
>>>>> tup+Guide\
>>>>> http://docs.ofbiz.org/display/OFBIZ/How+to+run+OFBiz+as+a+Service
>>>>> may help.
>>>>> then on your linux box
>>>>> load svn
>>>>> some use wget
>>>>> then you can use the svn commands to load ofbiz.
>>>>> http://docs.ofbiz.org/display/OFBADMIN/Demo+and+Test+Setup+Guide
>>>>>
>>>>> Philip Laing sent the following on 10/1/2007 5:06 PM:
>>>>>> Hi Fellas
>>>>>> I am preparing a Linux box with OFBiz + PostgreSQL ... I have had
>>>>> Compiere
>>>>>> and OpenBravo installed on my windows server boxes and have
>>>> investigated
>>>>>> TinyERP however OFBiz seems to fit in better with my business model
>>>>> which
>>>>>> largely consists of virtual warehousing and drop ship ecommerce.
This
>>>>> is my
>>>>>> first posting in this forum so excuse me if I have missed any
protocol
>>>>> or my
>>>>>> questions seem simplistic. So here we go
>>>>>>
>>>>>> 1. How do I download from the required SVN repositories using
windows?
>>>>>> 2. Search the list archives for threads other than scrolling through
>>>> one
>>>>> by
>>>>>> one?
>>>>>>
>>>>>> Thanks in advance
>>>>>> Wikitec
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>
>>>
>>>
>>>
>>
>
>
>

Re: Linux distro?

Posted by Jonathon -- Improov <jo...@improov.com>.

For 64-bit AMD? That'll be good. Last I saw, there were only versions for 64-bit Intel.

Jonathon

clearchris wrote:
> Sun did release a 64 bit version of java for linux, and I haven't
> encountered any issues with it and ofbiz, other than being incompatible with
> the 32bit pos hardware drivers.
> 
> C
> 
> -----Original Message-----
> From: Jonathon -- Improov [mailto:jonw@improov.com] 
> Sent: Tuesday, October 02, 2007 9:27 PM
> To: user@ofbiz.apache.org
> Subject: Re: Linux distro?
> 
> A couple of clients I have use 64-bit AMD machines. I recall there weren't
> any official Sun SDKs 
> supporting those machines. My clients were forced to use some other non-Sun
> SDKs. Not good. Lots 
> of bizarre issues.
> 
> As for 64-bit gotchas, I wouldn't be surprised. Newer hardwares often have
> new problems. I try to 
> go with mainstream models. Cluster up a few mainstream workhorses if we need
> more power.
> 
> Jonathon
> 
> Skip wrote:
>> BJ
>>
>> Thats a good idea, I would be particularly happy to hear about 64 bit
>> gotchas.  I seem to remember hearing about memory > 2gigs causing a
> problem
>> with multiple CPUs and > 2gigs of memory or some such.
>>
>> Skip
>>
>> -----Original Message-----
>> From: BJ Freeman [mailto:bjfree@free-man.net]
>> Sent: Tuesday, October 02, 2007 9:30 AM
>> To: user@ofbiz.apache.org
>> Subject: Re: Linux distro?
>>
>>
>> The only condsideration is if the distro you your plan to use supports
>> Sun SDK package.
>> as long as you have 1.5 or better on you box then you ok.
>> Fedora installs the opensource SDK and yum does not work to get the sun
> SDK.
>> Maybe we should put a doc file up that everyone can put what distro they
>> have tried and if they were sucessful or not.
>>
>>
>>
>> clearchris sent the following on 10/2/2007 8:41 AM:
>>> I plan on running Gentoo, though many disagree with that choice.
>>>
>>> http://linux.slashdot.org/linux/07/01/28/2227232.shtml
>>>
>>> I find that using the stable (non ~) branch with occasional upgrades to
>> ~x86
>>> (unstable) programs runs quite well.  It's the best of both worlds IMHO,
>> you
>>> can get the stable software and you can get the newer fixes that you
>>> inevitably will need.  Best of all, it provides a nice framework for
>>> managing that complexity.
>>>
>>> If you plan on using the POS application under linux, I'd highly suggest
>>> using a 32 bit distribution, even if you have a 64 bit processor.  Most
>>> (nearly all it seems) JavaPOS drivers have a native binary component that
>> is
>>> 32 bit.  While AMD processors can run 32 bit code natively, the binary
>>> drivers require 32 bit system libraries, etc, which can get a bit
>>> interesting to set up.
>>>
>>> My 2c.
>>>
>>> Chris
>>>
>>> -----Original Message-----
>>> From: Philip Laing [mailto:philip.laing@ascconsultants.com.au]
>>> Sent: Tuesday, October 02, 2007 12:05 AM
>>> To: user@ofbiz.apache.org
>>> Subject: Linux distro?
>>>
>>> Thanks skip - just looking at a review on CentOS at the moment.  Looks
>>> fairly impressive for server stability
>>>
>>> cheers
>>>
>>> Phil
>>>
>>>> -----Original Message-----
>>>> From: skip@theDevers [mailto:skip@thedevers.org]
>>>> Sent: Tuesday, 2 October 2007 1:59 PM
>>>> To: user@ofbiz.apache.org
>>>> Subject: RE: Download SVN Repository ... Linux distro?
>>>>
>>>> Instead of Fedora Core, give a look at CentOS.  Its a good deal more
>>>> stable.
>>>> I have had lots of weird problems with Fedora in the past (usually fixed
>>>> within a few weeks, but still a pain when it happens).
>>>>
>>>> Skip
>>>>
>>>> -----Original Message-----
>>>> From: Philip Laing [mailto:philip.laing@ascconsultants.com.au]
>>>> Sent: Monday, October 01, 2007 6:01 PM
>>>> To: user@ofbiz.apache.org
>>>> Subject: RE: Download SVN Repository ... Linux distro?
>>>>
>>>>
>>>> Thanks BJ ... Now what distro would be more suited these days?  I am
>>>> looking
>>>> at Fedora or Ununtu ... some may have preferences for viable reasons
>>>>
>>>> Thanks again ... quick reply to my question ... I think I am going to
>> like
>>>> setting up and configuring OFBiz
>>>>
>>>> Phil
>>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: BJ Freeman [mailto:bjfree@free-man.net]
>>>>> Sent: Tuesday, 2 October 2007 10:29 AM
>>>>> To: user@ofbiz.apache.org
>>>>> Subject: Re: Download SVN Repository
>>>>>
>>>>> first read
>>>>>
>> http://docs.ofbiz.org/display/OFBTECH/Apache+OFBiz+Technical+Production+Se
>>>>> tup+Guide\
>>>>> http://docs.ofbiz.org/display/OFBIZ/How+to+run+OFBiz+as+a+Service
>>>>> may help.
>>>>> then on your linux box
>>>>> load svn
>>>>> some use wget
>>>>> then you can use the svn commands to load ofbiz.
>>>>> http://docs.ofbiz.org/display/OFBADMIN/Demo+and+Test+Setup+Guide
>>>>>
>>>>> Philip Laing sent the following on 10/1/2007 5:06 PM:
>>>>>> Hi Fellas
>>>>>> I am preparing a Linux box with OFBiz + PostgreSQL ... I have had
>>>>> Compiere
>>>>>> and OpenBravo installed on my windows server boxes and have
>>>> investigated
>>>>>> TinyERP however OFBiz seems to fit in better with my business model
>>>>> which
>>>>>> largely consists of virtual warehousing and drop ship ecommerce.  This
>>>>> is my
>>>>>> first posting in this forum so excuse me if I have missed any protocol
>>>>> or my
>>>>>> questions seem simplistic. So here we go
>>>>>>
>>>>>> 1. How do I download from the required SVN repositories using windows?
>>>>>> 2. Search the list archives for threads other than scrolling through
>>>> one
>>>>> by
>>>>>> one?
>>>>>>
>>>>>> Thanks in advance
>>>>>> Wikitec
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>
>>>
>>>
>>>
>>
> 
> 
>

RE: Linux distro?

Posted by clearchris <cl...@hotmail.com>.

Sun did release a 64 bit version of java for linux, and I haven't
encountered any issues with it and ofbiz, other than being incompatible with
the 32bit pos hardware drivers.

C

-----Original Message-----
From: Jonathon -- Improov [mailto:jonw@improov.com] 
Sent: Tuesday, October 02, 2007 9:27 PM
To: user@ofbiz.apache.org
Subject: Re: Linux distro?

A couple of clients I have use 64-bit AMD machines. I recall there weren't
any official Sun SDKs 
supporting those machines. My clients were forced to use some other non-Sun
SDKs. Not good. Lots 
of bizarre issues.

As for 64-bit gotchas, I wouldn't be surprised. Newer hardwares often have
new problems. I try to 
go with mainstream models. Cluster up a few mainstream workhorses if we need
more power.

Jonathon

Skip wrote:
> BJ
> 
> Thats a good idea, I would be particularly happy to hear about 64 bit
> gotchas.  I seem to remember hearing about memory > 2gigs causing a
problem
> with multiple CPUs and > 2gigs of memory or some such.
> 
> Skip
> 
> -----Original Message-----
> From: BJ Freeman [mailto:bjfree@free-man.net]
> Sent: Tuesday, October 02, 2007 9:30 AM
> To: user@ofbiz.apache.org
> Subject: Re: Linux distro?
> 
> 
> The only condsideration is if the distro you your plan to use supports
> Sun SDK package.
> as long as you have 1.5 or better on you box then you ok.
> Fedora installs the opensource SDK and yum does not work to get the sun
SDK.
> 
> Maybe we should put a doc file up that everyone can put what distro they
> have tried and if they were sucessful or not.
> 
> 
> 
> clearchris sent the following on 10/2/2007 8:41 AM:
>> I plan on running Gentoo, though many disagree with that choice.
>>
>> http://linux.slashdot.org/linux/07/01/28/2227232.shtml
>>
>> I find that using the stable (non ~) branch with occasional upgrades to
> ~x86
>> (unstable) programs runs quite well.  It's the best of both worlds IMHO,
> you
>> can get the stable software and you can get the newer fixes that you
>> inevitably will need.  Best of all, it provides a nice framework for
>> managing that complexity.
>>
>> If you plan on using the POS application under linux, I'd highly suggest
>> using a 32 bit distribution, even if you have a 64 bit processor.  Most
>> (nearly all it seems) JavaPOS drivers have a native binary component that
> is
>> 32 bit.  While AMD processors can run 32 bit code natively, the binary
>> drivers require 32 bit system libraries, etc, which can get a bit
>> interesting to set up.
>>
>> My 2c.
>>
>> Chris
>>
>> -----Original Message-----
>> From: Philip Laing [mailto:philip.laing@ascconsultants.com.au]
>> Sent: Tuesday, October 02, 2007 12:05 AM
>> To: user@ofbiz.apache.org
>> Subject: Linux distro?
>>
>> Thanks skip - just looking at a review on CentOS at the moment.  Looks
>> fairly impressive for server stability
>>
>> cheers
>>
>> Phil
>>
>>> -----Original Message-----
>>> From: skip@theDevers [mailto:skip@thedevers.org]
>>> Sent: Tuesday, 2 October 2007 1:59 PM
>>> To: user@ofbiz.apache.org
>>> Subject: RE: Download SVN Repository ... Linux distro?
>>>
>>> Instead of Fedora Core, give a look at CentOS.  Its a good deal more
>>> stable.
>>> I have had lots of weird problems with Fedora in the past (usually fixed
>>> within a few weeks, but still a pain when it happens).
>>>
>>> Skip
>>>
>>> -----Original Message-----
>>> From: Philip Laing [mailto:philip.laing@ascconsultants.com.au]
>>> Sent: Monday, October 01, 2007 6:01 PM
>>> To: user@ofbiz.apache.org
>>> Subject: RE: Download SVN Repository ... Linux distro?
>>>
>>>
>>> Thanks BJ ... Now what distro would be more suited these days?  I am
>>> looking
>>> at Fedora or Ununtu ... some may have preferences for viable reasons
>>>
>>> Thanks again ... quick reply to my question ... I think I am going to
> like
>>> setting up and configuring OFBiz
>>>
>>> Phil
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: BJ Freeman [mailto:bjfree@free-man.net]
>>>> Sent: Tuesday, 2 October 2007 10:29 AM
>>>> To: user@ofbiz.apache.org
>>>> Subject: Re: Download SVN Repository
>>>>
>>>> first read
>>>>
> http://docs.ofbiz.org/display/OFBTECH/Apache+OFBiz+Technical+Production+Se
>>>> tup+Guide\
>>>> http://docs.ofbiz.org/display/OFBIZ/How+to+run+OFBiz+as+a+Service
>>>> may help.
>>>> then on your linux box
>>>> load svn
>>>> some use wget
>>>> then you can use the svn commands to load ofbiz.
>>>> http://docs.ofbiz.org/display/OFBADMIN/Demo+and+Test+Setup+Guide
>>>>
>>>> Philip Laing sent the following on 10/1/2007 5:06 PM:
>>>>> Hi Fellas
>>>>> I am preparing a Linux box with OFBiz + PostgreSQL ... I have had
>>>> Compiere
>>>>> and OpenBravo installed on my windows server boxes and have
>>> investigated
>>>>> TinyERP however OFBiz seems to fit in better with my business model
>>>> which
>>>>> largely consists of virtual warehousing and drop ship ecommerce.  This
>>>> is my
>>>>> first posting in this forum so excuse me if I have missed any protocol
>>>> or my
>>>>> questions seem simplistic. So here we go
>>>>>
>>>>> 1. How do I download from the required SVN repositories using windows?
>>>>> 2. Search the list archives for threads other than scrolling through
>>> one
>>>> by
>>>>> one?
>>>>>
>>>>> Thanks in advance
>>>>> Wikitec
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>
>>
>>
>>
>>
> 
>

RE: CRM - Customer Relationship Management facilities in OFBiz

Posted by Philip Laing <ph...@ascconsultants.com.au>.

Cool

Perhaps when I get that far with my implementation I might be able to help

cheers


> -----Original Message-----
> From: BJ Freeman [mailto:bjfree@free-man.net]
> Sent: Wednesday, 3 October 2007 1:26 PM
> To: user@ofbiz.apache.org
> Subject: Re: CRM - Customer Relationship Management facilities in OFBiz
> 
> there at least two efforts going that i know of.
> the data model pretty much has all that you need.
> Si's implementation does not totally integrate with the current data
> storage. it is built on ofbiz but is supported under opentaps.
> Mine is something I am bringing over from Java SWT and SQL db.
> Once I figure out how to show the UI I want in widgets I will release
> it. Currently for my clients I use a java sWT that connects to ofbiz.
> It is built entirely within the current ofbiz datamodel.
> as soon as I get some irons of the fire will focus on it more
> 
> 
> 
> Philip Laing sent the following on 10/2/2007 7:36 PM:
> > Thanks for your input relating my previous questions, I am interested in
> > implementing some sort of Helpdesk/CRM system and I am interested in
> what
> > facilities OFBiz already has
> >
> > Thanks
> > Phil
> >
> >
> >
> >

RE: CRM - Customer Relationship Management facilities in OFBiz

Posted by Philip Laing <ph...@ascconsultants.com.au>.

Please read down ...

> -----Original Message-----
> From: David E Jones [mailto:jonesde@hotwaxmedia.com]
> Sent: Thursday, 4 October 2007 4:12 AM
> To: user@ofbiz.apache.org
> Subject: Re: CRM - Customer Relationship Management facilities in OFBiz
> 
> 
> I'm not sure where this thread is leading or how it's related to
> OFBiz...
> 
> In any case, there is CRM functionality in OFBiz. The first step
> would be defining in a little more detail what you mean by "CRM"
> since that means very different things in different companies. 

[phil says] You are right Dave so I thought a little about this and wondered
why the major open source ERP players have heavily incorporated CRM into
their solutions.  What is CRM?  Wikitec broadly defines it as: 
** (CRM) is a broad term that covers concepts used by companies to manage
their relationships with customers, including the capture, storage and
analysis of customer, vendor, partner, and internal process information.**
http://en.wikipedia.org/wiki/Customer_relationship_management 

It appears the key areas CRM follow are:
* Marketing
	o Planning
	o Campaign management
 	o Lead management
* Sales
	o Opportunity management
 	o Quotation and sales order management
	o Activity management
* Service
	o Service Order Management
	o Service Contract Management
 	o Planned Services management
 	o Warranty Management
 	o Installed Base (Equipment) Management
	o SLA Management
 	o Resource Planning and Scheduling
 	o Knowledge Management (FAQs, How to guides)
 	o Call Center Support
 	o Resource Planning and Workforce Management
 
> OFBiz
> does offer a single view into customer interactions including web
> site visits, phone/email/in-person/etc communications, requests,
> quotes, orders, shipments, invoices, payments, balance accounts,
> projects, calendar events, and many other things. You can also
> classify parties for marketing and sales, and do things like
> marketing campaigns including reference codes via email, snail mail,
> whatever.

[phil says] As you can see from the above OFBiz current CRM does not cut it
at this point in time and certainly doesn't fit in with my business needs.

> If you're looking for simple desktop contact management something
> like ACT or even salesforce.com would be better. If you're looking
> for enterprise CRM (especially a business or industry specific
> incarnation of such) then OFBiz a great basis for the effort.

[phil says] Yes I agree, however as a matrix comparison this sort of
information if certainly needed prior to implementation.  

Having said that it certainly looks like full CRM functionality has indeed
been incorporated in Opentaps, even though it does not totally integrate
with the current data storage and other developers and BJ Freeman which
does.  BJ's solution, which appears to make the most sense, will not be
placed on the backburners for the above reasons

Phil

> -David
> 
> 
> On Oct 3, 2007, at 11:07 AM, skip@theDevers wrote:
> 
> > I'd like to see the SWT code as it is.  To heck with translating it
> > to use
> > web based widgets.
> >
> > I gotta set up a web site soon to hold code like this.
> >
> > Skip
> >
> >
> > -----Original Message-----
> > From: BJ Freeman [mailto:bjfree@free-man.net]
> > Sent: Wednesday, October 03, 2007 3:06 AM
> > To: user@ofbiz.apache.org
> > Subject: Re: CRM - Customer Relationship Management facilities in
> > OFBiz
> >
> >
> > basically yes.
> > the tool i used added some classes to better manage things.
> > http://www.elance.com/p/?
> > q=eolproviderprofile&view_person=BJFreeman&catid=10
> > 182#tab=1
> > click on Java CRM
> >
> > skip@theDevers sent the following on 10/2/2007 8:55 PM:
> >> BJ
> >>
> >> SWT as in Eclipse SWT?
> >>
> >> Skip
> >>
> >> -----Original Message-----
> >> From: BJ Freeman [mailto:bjfree@free-man.net]
> >> Sent: Tuesday, October 02, 2007 8:26 PM
> >> To: user@ofbiz.apache.org
> >> Subject: Re: CRM - Customer Relationship Management facilities in
> >> OFBiz
> >>
> >>
> >> there at least two efforts going that i know of.
> >> the data model pretty much has all that you need.
> >> Si's implementation does not totally integrate with the current data
> >> storage. it is built on ofbiz but is supported under opentaps.
> >> Mine is something I am bringing over from Java SWT and SQL db.
> >> Once I figure out how to show the UI I want in widgets I will release
> >> it. Currently for my clients I use a java sWT that connects to ofbiz.
> >> It is built entirely within the current ofbiz datamodel.
> >> as soon as I get some irons of the fire will focus on it more
> >>
> >>
> >>
> >> Philip Laing sent the following on 10/2/2007 7:36 PM:
> >>> Thanks for your input relating my previous questions, I am
> >>> interested in
> >>> implementing some sort of Helpdesk/CRM system and I am interested
> >>> in what
> >>> facilities OFBiz already has
> >>>
> >>> Thanks
> >>> Phil
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >>
> >

Re: CRM - Customer Relationship Management facilities in OFBiz

Posted by BJ Freeman <bj...@free-man.net>.

I agree, it is not pulled together in one place.

David E Jones sent the following on 10/3/2007 12:02 PM:
> 
> 
> 
> On Oct 3, 2007, at 12:59 PM, BJ Freeman wrote:
> 
>> For my part i was sharing what I am doing with ofbiz.
>>
> 
> That's totally fine BJ. My point was to make it clear that OFBiz does
> have lots of CRM functionality OOTB, and try to direct the thread back
> to what this mailing list is meant for. Nothing you wrote was invalid or
> bad or anything.
> 
> -David
> 
> 
> 
>

Re: CRM - Customer Relationship Management facilities in OFBiz

Posted by David E Jones <jo...@hotwaxmedia.com>.

On Oct 3, 2007, at 12:59 PM, BJ Freeman wrote:

> For my part i was sharing what I am doing with ofbiz.
>

That's totally fine BJ. My point was to make it clear that OFBiz does  
have lots of CRM functionality OOTB, and try to direct the thread  
back to what this mailing list is meant for. Nothing you wrote was  
invalid or bad or anything.

-David

Re: CRM - Customer Relationship Management facilities in OFBiz

Posted by BJ Freeman <bj...@free-man.net>.

For my part i was sharing what I am doing with ofbiz.

David E Jones sent the following on 10/3/2007 11:11 AM:
> 
> I'm not sure where this thread is leading or how it's related to OFBiz...
> 
> In any case, there is CRM functionality in OFBiz. The first step would
> be defining in a little more detail what you mean by "CRM" since that
> means very different things in different companies. OFBiz does offer a
> single view into customer interactions including web site visits,
> phone/email/in-person/etc communications, requests, quotes, orders,
> shipments, invoices, payments, balance accounts, projects, calendar
> events, and many other things. You can also classify parties for
> marketing and sales, and do things like marketing campaigns including
> reference codes via email, snail mail, whatever.
> 
> If you're looking for simple desktop contact management something like
> ACT or even salesforce.com would be better. If you're looking for
> enterprise CRM (especially a business or industry specific incarnation
> of such) then OFBiz a great basis for the effort.
> 
> -David
> 
> 
> On Oct 3, 2007, at 11:07 AM, skip@theDevers wrote:
> 
>> I'd like to see the SWT code as it is.  To heck with translating it to
>> use
>> web based widgets.
>>
>> I gotta set up a web site soon to hold code like this.
>>
>> Skip
>>
>>
>> -----Original Message-----
>> From: BJ Freeman [mailto:bjfree@free-man.net]
>> Sent: Wednesday, October 03, 2007 3:06 AM
>> To: user@ofbiz.apache.org
>> Subject: Re: CRM - Customer Relationship Management facilities in OFBiz
>>
>>
>> basically yes.
>> the tool i used added some classes to better manage things.
>> http://www.elance.com/p/?q=eolproviderprofile&view_person=BJFreeman&catid=10
>>
>> 182#tab=1
>> click on Java CRM
>>
>> skip@theDevers sent the following on 10/2/2007 8:55 PM:
>>> BJ
>>>
>>> SWT as in Eclipse SWT?
>>>
>>> Skip
>>>
>>> -----Original Message-----
>>> From: BJ Freeman [mailto:bjfree@free-man.net]
>>> Sent: Tuesday, October 02, 2007 8:26 PM
>>> To: user@ofbiz.apache.org
>>> Subject: Re: CRM - Customer Relationship Management facilities in OFBiz
>>>
>>>
>>> there at least two efforts going that i know of.
>>> the data model pretty much has all that you need.
>>> Si's implementation does not totally integrate with the current data
>>> storage. it is built on ofbiz but is supported under opentaps.
>>> Mine is something I am bringing over from Java SWT and SQL db.
>>> Once I figure out how to show the UI I want in widgets I will release
>>> it. Currently for my clients I use a java sWT that connects to ofbiz.
>>> It is built entirely within the current ofbiz datamodel.
>>> as soon as I get some irons of the fire will focus on it more
>>>
>>>
>>>
>>> Philip Laing sent the following on 10/2/2007 7:36 PM:
>>>> Thanks for your input relating my previous questions, I am
>>>> interested in
>>>> implementing some sort of Helpdesk/CRM system and I am interested in
>>>> what
>>>> facilities OFBiz already has
>>>>
>>>> Thanks
>>>> Phil
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
> 
> 
> 
>

RE: CRM - Customer Relationship Management facilities in OFBiz

Posted by Philip Laing <ph...@ascconsultants.com.au>.

Hi Skip

Is the solution you are working on tapping into the existing database?  If
that is correct, it appears to be the way to go.  Java is entirely different
to Java script, what's more entire programs such as Open Office Org,
Compiere and many more are written in Java, I feel a small module that
concentrates on area that is obviously missing in OFBiz at present written
in Java is not a concern.  The concern is not making available an intrinsic
function that most ERP operations incorporate is something to be concerned
about.  

I have just been browsing previous threads on CRM and it seems the demand is
high.  If your solution is able to integrate with the current dbase
framework well, I feel this would be the next natural progression to OFBiz's
evolution.

Keep up your good work, and hopefully you will receive the support your
efforts deserve.

Cheers
Phil 

> -----Original Message-----
> From: skip@theDevers [mailto:skip@thedevers.org]
> Sent: Thursday, 4 October 2007 2:54 PM
> To: user@ofbiz.apache.org
> Subject: RE: CRM - Customer Relationship Management facilities in OFBiz
> 
> Johathon
> 
> Hmmm, you've almost got me convinced to give this up.  So convinced in
> fact
> that I am gonna forward this email on to my current customer and get his
> reaction.  It's well thought out and you obviously spent a great deal of
> time thinking about it and I thank you for it lavishly.
> 
> Still, I have these arguments in favor to offer:
> 
> 1.  Backoffice personell are expensive.  Even saving them 10 minutes
> (that's
> 10 seconds a transaction or less) a day translates to $3000 a year even
> for
> the lower paid ones, and this is per-person.  I have timed myself using
> the
> Ofbiz "Order Entry" screen to enter a two item sale and the desktop Java
> based order entry application I am currently finishing.  The results?  It
> takes 20 seconds less on simple orders (Finalize with defaults) and 45
> seconds less with complicated ones using the Java app. And, all my code is
> using the stock Ofbiz services to do the real work so it's fairly simple
> to
> write.  The difference in time is because I can change the control having
> the input focus intelligently and I don't have to wait for brower repaints
> between atomic operations.  A fast operator can go as fast as they can
> type.
> I know I can achieve the same effect with ajax, but if I have to write
> these
> apps from scratch anyway, why not take advantage of the extra horsepower
> and
> compiled Java?  By the way, the nearly finished Java app is surprisingly
> small.  With Ofbiz code doing the grunt work, I can spend my time making
> the
> GUI fast, easy, and smart.
> 
> 2.  "Also, the move forward is to "dumb down" the client terminals (cheap
> to
> deploy, scalable)."  I would partially disagree with this although it is
> repeated a lot.  This was certainly true a couple of years ago, but
> lately,
> we are heading back in the other direction.  Witness the move to Ajax
> backed
> Javascript as an example. It takes almost no time to code a GUI with
> Netbeans.  No such tools currently exist (that I know of) for Ajax backed
> apps.  Also. go look at the sales stats for Dell and HP and you will see
> that the  majority of their sales are to business and it shows no signs of
> slowing (although it is not increasing as fast as it was a few years ago).
> 
> 3.  "Even if the client terminals just happen to be blazing fast enough
> for
> graphics-intensive work...".  Graphics-intensive capability is more a
> factor
> of the video card than the CPU.  EVERY desktop I see with an A/R or A/P
> person in the chair is capable of running Ofbiz, Word and Excel at the
> same
> time.  On my test box, I have Ofbiz running with Netbeans, Visual Studio,
> Gaim, and Outlook and it's no smoker and joker.
> 
> 4.  "In production, servers aren't hit all the time. There are peak
> periods,
> and there are lull periods."  If the brains are on the user's desktop,
> there
> are no lull or peaks at any time (and no associated aggravation).  Their
> work is never interrupted or slowed (assuming the database server is not
> overloaded.)
> 
> 
> 5.  "Those folks writing the "offloading algorithms" won't know how
> fast/slow my computer is."  Gads Jonathon, I couldnt agree more.  I get
> aggravated daily waiting for Javascript intensive web pages to download.
> However, I am not running javascript, but blazingly fast compiled Java.
> If
> the user's machine doesnt have the guts, I wouldn't install Ofbiz on it.
> They can use a browser to access the same funcionality.
> 
> 
> Hmmm, now I've almost convinced myself to carry on. :)
> 
> Cheers
> 
> Skip
> 
> 
> -----Original Message-----
> From: Jonathon -- Improov [mailto:jonw@improov.com]
> Sent: Wednesday, October 03, 2007 7:43 PM
> To: user@ofbiz.apache.org
> Subject: Re: CRM - Customer Relationship Management facilities in OFBiz
> 
> 
>  > You might be surprised by how expensive such a solution would be to
>  > create/maintain/deploy and how little it will help on server resources.
> 
> I have many clients wanting to move away from that distributed (client
> codes) model to the
> centralized (server codes) model. Yes, it is proving to be expensive.
> Kinda
> "tried and tested" to
> be expensive, actually.
> 
> "Create/maintain/deploy" are all human activities. Will be inordinately
> expensive to create
> artificial intelligence to do all that. In general (with our current
> state-of-the-art of AI), it
> is cheaper to simply upgrade the server hardware. Yes, computer hardware
> speed improvement may be
> slowing down now (used to be doubling every 1.5 years?). But there will
> surely be something new
> coming up (quantum computers, multi-state logic units, etc), unless we're
> suddenly hit by an
> epidemic that halves human intelligence every 1.5 years. (Or I infect all
> you guys with my stupidity).
> 
> Also, the move forward is to "dumb down" the client terminals (cheap to
> deploy, scalable). Even if
> the client terminals just happen to be blazing fast enough for
> graphics-intensive work, perhaps
> those terminals' users' job scope is to do graphics-intensive work on a
> regular basis? Putting a
> part of OFBiz into those machines will compromise the efficiency of their
> graphics-intensive work.
> 
> As for "You might be surprised", I'm ALWAYS surprised when it comes to
> doing
> optimization work!
> Optimization needs are very hard to calculate and predict by hand. Rather
> than spend weeks using
> complex maths and theories to predict (presume, rather) bottle-necks, it's
> easier to spend a
> couple of hours to do an actual measurement of computation speeds.
> 
>  > You might also be surprised by how capable servers are of handling
>  > concurrent load, how different performance tends to be in a development
>  > versus production environment, and for certain things how easy it is to
>  > tune them once the slowest stuff has been identified.
> 
> In production, servers aren't hit all the time. There are peak periods,
> and
> there are lull
> periods. To handle such cases, clustering and load-balancing is the usual
> practice. The diff
> between clustering servers and using smart client terminals, both being
> distributed models, is
> this... it's easier to monitor and tune a few servers than to do so for
> hundreds of client terminals.
> 
> Also, consider how irritating javascript is getting to be, those that try
> to
> offload huge amounts
> of servers' workloads into our personal computers. Those folks writing the
> "offloading algorithms"
> won't know how fast/slow my computer is, and could render my computer
> completely useless by
> overloading it.
> 
> But before going into clustering, it is often adequate to spot the
> bottle-necks in a single
> server, and optimize just those areas. That'll help the OFBiz framework
> and
> help the OFBiz
> community too.
> 
> For all the optimization smarts we have, I must say that I had
> over-optimized before in my career.
> In business, over-optimizing a system isn't "passing with flying colors",
> but actually translates
> into a loss. While it is great to "push the envelope", it'll help in
> thesis
> writing more than in
> business. Study the bottle-necks in production settings, and fix just
> those.
> 
> Still, please feel free to over-optimize the OFBiz framework! That's a
> different scenario. Huge ROI.
> 
> Jonathon
> 
> David E Jones wrote:
> >
> > You might be surprised by how expensive such a solution would be to
> > create/maintain/deploy and how little it will help on server resources.
> > You might also be surprised by how capable servers are of handling
> > concurrent load, how different performance tends to be in a development
> > versus production environment, and for certain things how easy it is to
> > tune them once the slowest stuff has been identified.
> >
> > -David
> >
> >
> > On Oct 3, 2007, at 1:05 PM, skip@theDevers wrote:
> >
> >> David
> >>
> >> This issue here to me asset utilization.  In a typical mid-sized
> company,
> >> there are dozens or hundreds of desktop computers that their user use
> >> to do
> >> their daily work.  If the user is using a browser to access logic on
> >> one of
> >> Ofbiz servers, the desktop is under-utilized.  By tying in a desktop
> >> application to Ofbiz (i.e. running an entity engine on the desktop
> >> tied to
> >> the same database as the main ofbiz servers and running xml setups
> >> identical
> >> to the servers), that workload is performed on the users desktop and
> >> not on
> >> the main ofbiz servers thereby freeing the server for functionality
> that
> >> REQUIRES browser based access.
> >>
> >> This does not in any way supplant Ofbiz, it enhances it by
> >> distributing the
> >> workload and giving the clerical user a better amd more responsive
> >> experience.
> >>
> >> As some examples, my recent testing of the sales order functionality
> >> shows
> >> that it takes ~ 200 msecs to complete the "userLogin" service or 120
> >> msecs
> >> to complete "calculateProductPrice" (these numbers are from the ofbiz
> log
> >> file on a fairly fast machine with lots of debug output).  If this is
> all
> >> done on the main ofbiz servers about 5 of the former and 10 of the
> >> later can
> >> be done simultaneously to maintain a reasonable lag time.  If the load
> is
> >> spread out among say 8 desktops and 2 browser accesses, everyone has a
> >> really good experience.
> >>
> >> The only drawback to this all is that if the server configuration
> >> changes,
> >> the desktops must be patched as well.  In practice, that is not a big
> >> issue.
> >>
> >> So, it makes great sense to me to write desktop applications for common
> >> backoffice functions.
> >>
> >> I am currently working on a suite of such applications, hence my
> >> interest in
> >> BJs SWT based CRM.
> >>
> >> Skip
> >>
> >> -----Original Message-----
> >> From: David E Jones [mailto:jonesde@hotwaxmedia.com]
> >> Sent: Wednesday, October 03, 2007 11:12 AM
> >> To: user@ofbiz.apache.org
> >> Subject: Re: CRM - Customer Relationship Management facilities in OFBiz
> >>
> >>
> >>
> >> I'm not sure where this thread is leading or how it's related to
> >> OFBiz...
> >>
> >> In any case, there is CRM functionality in OFBiz. The first step
> >> would be defining in a little more detail what you mean by "CRM"
> >> since that means very different things in different companies. OFBiz
> >> does offer a single view into customer interactions including web
> >> site visits, phone/email/in-person/etc communications, requests,
> >> quotes, orders, shipments, invoices, payments, balance accounts,
> >> projects, calendar events, and many other things. You can also
> >> classify parties for marketing and sales, and do things like
> >> marketing campaigns including reference codes via email, snail mail,
> >> whatever.
> >>
> >> If you're looking for simple desktop contact management something
> >> like ACT or even salesforce.com would be better. If you're looking
> >> for enterprise CRM (especially a business or industry specific
> >> incarnation of such) then OFBiz a great basis for the effort.
> >>
> >> -David
> >>
> >>
> >> On Oct 3, 2007, at 11:07 AM, skip@theDevers wrote:
> >>
> >>> I'd like to see the SWT code as it is.  To heck with translating it
> >>> to use
> >>> web based widgets.
> >>>
> >>> I gotta set up a web site soon to hold code like this.
> >>>
> >>> Skip
> >>>
> >>>
> >>> -----Original Message-----
> >>> From: BJ Freeman [mailto:bjfree@free-man.net]
> >>> Sent: Wednesday, October 03, 2007 3:06 AM
> >>> To: user@ofbiz.apache.org
> >>> Subject: Re: CRM - Customer Relationship Management facilities in
> >>> OFBiz
> >>>
> >>>
> >>> basically yes.
> >>> the tool i used added some classes to better manage things.
> >>> http://www.elance.com/p/?
> >>> q=eolproviderprofile&view_person=BJFreeman&catid=10
> >>> 182#tab=1
> >>> click on Java CRM
> >>>
> >>> skip@theDevers sent the following on 10/2/2007 8:55 PM:
> >>>> BJ
> >>>>
> >>>> SWT as in Eclipse SWT?
> >>>>
> >>>> Skip
> >>>>
> >>>> -----Original Message-----
> >>>> From: BJ Freeman [mailto:bjfree@free-man.net]
> >>>> Sent: Tuesday, October 02, 2007 8:26 PM
> >>>> To: user@ofbiz.apache.org
> >>>> Subject: Re: CRM - Customer Relationship Management facilities in
> >>>> OFBiz
> >>>>
> >>>>
> >>>> there at least two efforts going that i know of.
> >>>> the data model pretty much has all that you need.
> >>>> Si's implementation does not totally integrate with the current data
> >>>> storage. it is built on ofbiz but is supported under opentaps.
> >>>> Mine is something I am bringing over from Java SWT and SQL db.
> >>>> Once I figure out how to show the UI I want in widgets I will release
> >>>> it. Currently for my clients I use a java sWT that connects to ofbiz.
> >>>> It is built entirely within the current ofbiz datamodel.
> >>>> as soon as I get some irons of the fire will focus on it more
> >>>>
> >>>>
> >>>>
> >>>> Philip Laing sent the following on 10/2/2007 7:36 PM:
> >>>>> Thanks for your input relating my previous questions, I am
> >>>>> interested in
> >>>>> implementing some sort of Helpdesk/CRM system and I am interested
> >>>>> in what
> >>>>> facilities OFBiz already has
> >>>>>
> >>>>> Thanks
> >>>>> Phil
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >>
> >

Re: CRM - Customer Relationship Management facilities in OFBiz

Posted by BJ Freeman <bj...@free-man.net>.

Just to through in something not discussed.
When I went to Java it was because:
1) i could put an application on the webpage, that worked on the client
cpu for UI.
2) I could detach the Java app from the webpage so it sat on the users
system by click of a mouse.

so I had distribution as well as installation all in one packages.
I still had to talk to the DB Server, so I have had the problem of Lan
speeds to deal with and how to encrypt data between the server and client.

My first step, was to change the communication from DB to ofbiz, which
was mostly slowed by me learning ofbiz and it structural and functional
changes it went thru in the last 3-4 years.

My tool for Creating UI in java is simple to use. It creates a XML file
as well as the actual SWT code.

My tinkering has been to use xslt files to convert the xml created to
ofbiz widgets. Still have to put in code relative to ofbiz. but the
learning curve is the same if you do the Widgets from scratch or my way.

I also am aware of the the OLPC initiative for foreign countries. those
Laptops use distributed processing to build a complex system.

Jonathon -- Improov sent the following on 10/3/2007 7:42 PM:
>> You might be surprised by how expensive such a solution would be to
>> create/maintain/deploy and how little it will help on server resources.
> 
> I have many clients wanting to move away from that distributed (client
> codes) model to the centralized (server codes) model. Yes, it is proving
> to be expensive. Kinda "tried and tested" to be expensive, actually.
> 
> "Create/maintain/deploy" are all human activities. Will be inordinately
> expensive to create artificial intelligence to do all that. In general
> (with our current state-of-the-art of AI), it is cheaper to simply
> upgrade the server hardware. Yes, computer hardware speed improvement
> may be slowing down now (used to be doubling every 1.5 years?). But
> there will surely be something new coming up (quantum computers,
> multi-state logic units, etc), unless we're suddenly hit by an epidemic
> that halves human intelligence every 1.5 years. (Or I infect all you
> guys with my stupidity).
> 
> Also, the move forward is to "dumb down" the client terminals (cheap to
> deploy, scalable). Even if the client terminals just happen to be
> blazing fast enough for graphics-intensive work, perhaps those
> terminals' users' job scope is to do graphics-intensive work on a
> regular basis? Putting a part of OFBiz into those machines will
> compromise the efficiency of their graphics-intensive work.
> 
> As for "You might be surprised", I'm ALWAYS surprised when it comes to
> doing optimization work! Optimization needs are very hard to calculate
> and predict by hand. Rather than spend weeks using complex maths and
> theories to predict (presume, rather) bottle-necks, it's easier to spend
> a couple of hours to do an actual measurement of computation speeds.
> 
>> You might also be surprised by how capable servers are of handling
>> concurrent load, how different performance tends to be in a development
>> versus production environment, and for certain things how easy it is to
>> tune them once the slowest stuff has been identified.
> 
> In production, servers aren't hit all the time. There are peak periods,
> and there are lull periods. To handle such cases, clustering and
> load-balancing is the usual practice. The diff between clustering
> servers and using smart client terminals, both being distributed models,
> is this... it's easier to monitor and tune a few servers than to do so
> for hundreds of client terminals.
> 
> Also, consider how irritating javascript is getting to be, those that
> try to offload huge amounts of servers' workloads into our personal
> computers. Those folks writing the "offloading algorithms" won't know
> how fast/slow my computer is, and could render my computer completely
> useless by overloading it.
> 
> But before going into clustering, it is often adequate to spot the
> bottle-necks in a single server, and optimize just those areas. That'll
> help the OFBiz framework and help the OFBiz community too.
> 
> For all the optimization smarts we have, I must say that I had
> over-optimized before in my career. In business, over-optimizing a
> system isn't "passing with flying colors", but actually translates into
> a loss. While it is great to "push the envelope", it'll help in thesis
> writing more than in business. Study the bottle-necks in production
> settings, and fix just those.
> 
> Still, please feel free to over-optimize the OFBiz framework! That's a
> different scenario. Huge ROI.
> 
> Jonathon
> 
> David E Jones wrote:
>>
>> You might be surprised by how expensive such a solution would be to
>> create/maintain/deploy and how little it will help on server
>> resources. You might also be surprised by how capable servers are of
>> handling concurrent load, how different performance tends to be in a
>> development versus production environment, and for certain things how
>> easy it is to tune them once the slowest stuff has been identified.
>>
>> -David
>>
>>
>> On Oct 3, 2007, at 1:05 PM, skip@theDevers wrote:
>>
>>> David
>>>
>>> This issue here to me asset utilization.  In a typical mid-sized
>>> company,
>>> there are dozens or hundreds of desktop computers that their user use
>>> to do
>>> their daily work.  If the user is using a browser to access logic on
>>> one of
>>> Ofbiz servers, the desktop is under-utilized.  By tying in a desktop
>>> application to Ofbiz (i.e. running an entity engine on the desktop
>>> tied to
>>> the same database as the main ofbiz servers and running xml setups
>>> identical
>>> to the servers), that workload is performed on the users desktop and
>>> not on
>>> the main ofbiz servers thereby freeing the server for functionality that
>>> REQUIRES browser based access.
>>>
>>> This does not in any way supplant Ofbiz, it enhances it by
>>> distributing the
>>> workload and giving the clerical user a better amd more responsive
>>> experience.
>>>
>>> As some examples, my recent testing of the sales order functionality
>>> shows
>>> that it takes ~ 200 msecs to complete the "userLogin" service or 120
>>> msecs
>>> to complete "calculateProductPrice" (these numbers are from the ofbiz
>>> log
>>> file on a fairly fast machine with lots of debug output).  If this is
>>> all
>>> done on the main ofbiz servers about 5 of the former and 10 of the
>>> later can
>>> be done simultaneously to maintain a reasonable lag time.  If the
>>> load is
>>> spread out among say 8 desktops and 2 browser accesses, everyone has a
>>> really good experience.
>>>
>>> The only drawback to this all is that if the server configuration
>>> changes,
>>> the desktops must be patched as well.  In practice, that is not a big
>>> issue.
>>>
>>> So, it makes great sense to me to write desktop applications for common
>>> backoffice functions.
>>>
>>> I am currently working on a suite of such applications, hence my
>>> interest in
>>> BJs SWT based CRM.
>>>
>>> Skip
>>>
>>> -----Original Message-----
>>> From: David E Jones [mailto:jonesde@hotwaxmedia.com]
>>> Sent: Wednesday, October 03, 2007 11:12 AM
>>> To: user@ofbiz.apache.org
>>> Subject: Re: CRM - Customer Relationship Management facilities in OFBiz
>>>
>>>
>>>
>>> I'm not sure where this thread is leading or how it's related to
>>> OFBiz...
>>>
>>> In any case, there is CRM functionality in OFBiz. The first step
>>> would be defining in a little more detail what you mean by "CRM"
>>> since that means very different things in different companies. OFBiz
>>> does offer a single view into customer interactions including web
>>> site visits, phone/email/in-person/etc communications, requests,
>>> quotes, orders, shipments, invoices, payments, balance accounts,
>>> projects, calendar events, and many other things. You can also
>>> classify parties for marketing and sales, and do things like
>>> marketing campaigns including reference codes via email, snail mail,
>>> whatever.
>>>
>>> If you're looking for simple desktop contact management something
>>> like ACT or even salesforce.com would be better. If you're looking
>>> for enterprise CRM (especially a business or industry specific
>>> incarnation of such) then OFBiz a great basis for the effort.
>>>
>>> -David
>>>
>>>
>>> On Oct 3, 2007, at 11:07 AM, skip@theDevers wrote:
>>>
>>>> I'd like to see the SWT code as it is.  To heck with translating it
>>>> to use
>>>> web based widgets.
>>>>
>>>> I gotta set up a web site soon to hold code like this.
>>>>
>>>> Skip
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: BJ Freeman [mailto:bjfree@free-man.net]
>>>> Sent: Wednesday, October 03, 2007 3:06 AM
>>>> To: user@ofbiz.apache.org
>>>> Subject: Re: CRM - Customer Relationship Management facilities in
>>>> OFBiz
>>>>
>>>>
>>>> basically yes.
>>>> the tool i used added some classes to better manage things.
>>>> http://www.elance.com/p/?
>>>> q=eolproviderprofile&view_person=BJFreeman&catid=10
>>>> 182#tab=1
>>>> click on Java CRM
>>>>
>>>> skip@theDevers sent the following on 10/2/2007 8:55 PM:
>>>>> BJ
>>>>>
>>>>> SWT as in Eclipse SWT?
>>>>>
>>>>> Skip
>>>>>
>>>>> -----Original Message-----
>>>>> From: BJ Freeman [mailto:bjfree@free-man.net]
>>>>> Sent: Tuesday, October 02, 2007 8:26 PM
>>>>> To: user@ofbiz.apache.org
>>>>> Subject: Re: CRM - Customer Relationship Management facilities in
>>>>> OFBiz
>>>>>
>>>>>
>>>>> there at least two efforts going that i know of.
>>>>> the data model pretty much has all that you need.
>>>>> Si's implementation does not totally integrate with the current data
>>>>> storage. it is built on ofbiz but is supported under opentaps.
>>>>> Mine is something I am bringing over from Java SWT and SQL db.
>>>>> Once I figure out how to show the UI I want in widgets I will release
>>>>> it. Currently for my clients I use a java sWT that connects to ofbiz.
>>>>> It is built entirely within the current ofbiz datamodel.
>>>>> as soon as I get some irons of the fire will focus on it more
>>>>>
>>>>>
>>>>>
>>>>> Philip Laing sent the following on 10/2/2007 7:36 PM:
>>>>>> Thanks for your input relating my previous questions, I am
>>>>>> interested in
>>>>>> implementing some sort of Helpdesk/CRM system and I am interested
>>>>>> in what
>>>>>> facilities OFBiz already has
>>>>>>
>>>>>> Thanks
>>>>>> Phil
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
> 
> 
> 
>

Re: availableToPromiseTotal

Posted by Jonathon -- Improov <jo...@improov.com>.

Agreed. The field availableToPromise should only be updated when an actual commitment is made.

Same for inventory reservations.

Question is, will the availableToPromise field, if value is 1, be put into negative value when a 
few customers do an "add-to-cart" at the same time, and then check out at the same time? I think 
not. A simple race should settle it, and decide which customer gets the single available item.

For inventory reservations, I think an exception is thrown during order creation if the inventory 
is no longer available to be reserved. That is, if it is somehow taken away between "add-to-cart" 
and "order creation".

Jonathon

David E Jones wrote:
> 
> Most retailers don't consider an add to cart to be sufficient commitment 
> on the customer's part to even try to guarantee that they will get it. I 
> have actually done stuff like that before, but I really wouldn't 
> recommend it because you end up with lots of funny exceptions and it is 
> too easy for data to get in bad states, or for reservations to never get 
> cleaned up and such. This also puts a lot of traffic on certain entities 
> too and can increase chances of locking and other concurrency problems.
> 
> If you DO want to do this, I would recommend NOT using the current 
> availableToPromise counts and the OrderItemShipGrpInvRes records as 
> those are meant for something a little different, and a little more 
> important to get write (ie reduce chances of interfering with it and 
> what what).
> 
> -David
> 
> 
> On Oct 4, 2007, at 7:04 PM, skip@theDevers wrote:
> 
>> In my wonderings through the ofbiz code, I have noted that
>> availableToPromiseTotal for items on an order is not reduced until
>> createOrder is called.  I expected availableToPromiseTotal to be reduced
>> (assuming there was any) when the "Add To Order" button was pressed.
>>
>> This means that if there are 10 people using your system and 5 want 
>> the same
>> product which has 3 in stock, all 5 will show AOH=3 when they press 
>> Add to
>> Order, but two will get their order rejected when the order is processed.
>>
>> This is easy enough to change, but I wondered why it was done this way in
>> case I am missing something.
>>
>> Skip
>>
>

Re: availableToPromiseTotal

Posted by David E Jones <jo...@hotwaxmedia.com>.

Abandoned carts are something we already detect, and save the  
contents of to the database for analysis. It is possible to do  
something similar to cancel reservations, but this is one of many  
things that you'll run into that just isn't totally reliable and over  
thousands of operations eventually adds up to lots of work to monitor  
and clean up.

-David


On Oct 4, 2007, at 7:35 PM, skip@theDevers wrote:

> Thanks David, I'll use the code as is and see if anyone bitches.  I  
> agree
> that the logic is complicated, especially considering that a person  
> can just
> exit their browser and leave things hanging.
>
> Skip
>
> -----Original Message-----
> From: David E Jones [mailto:jonesde@hotwaxmedia.com]
> Sent: Thursday, October 04, 2007 6:21 PM
> To: user@ofbiz.apache.org
> Subject: Re: availableToPromiseTotal
>
>
>
> Most retailers don't consider an add to cart to be sufficient
> commitment on the customer's part to even try to guarantee that they
> will get it. I have actually done stuff like that before, but I
> really wouldn't recommend it because you end up with lots of funny
> exceptions and it is too easy for data to get in bad states, or for
> reservations to never get cleaned up and such. This also puts a lot
> of traffic on certain entities too and can increase chances of
> locking and other concurrency problems.
>
> If you DO want to do this, I would recommend NOT using the current
> availableToPromise counts and the OrderItemShipGrpInvRes records as
> those are meant for something a little different, and a little more
> important to get write (ie reduce chances of interfering with it and
> what what).
>
> -David
>
>
> On Oct 4, 2007, at 7:04 PM, skip@theDevers wrote:
>
>> In my wonderings through the ofbiz code, I have noted that
>> availableToPromiseTotal for items on an order is not reduced until
>> createOrder is called.  I expected availableToPromiseTotal to be
>> reduced
>> (assuming there was any) when the "Add To Order" button was pressed.
>>
>> This means that if there are 10 people using your system and 5 want
>> the same
>> product which has 3 in stock, all 5 will show AOH=3 when they press
>> Add to
>> Order, but two will get their order rejected when the order is
>> processed.
>>
>> This is easy enough to change, but I wondered why it was done this
>> way in
>> case I am missing something.
>>
>> Skip
>>
>
>

RE: availableToPromiseTotal

Posted by "skip@theDevers" <sk...@thedevers.org>.

Thanks David, I'll use the code as is and see if anyone bitches.  I agree
that the logic is complicated, especially considering that a person can just
exit their browser and leave things hanging.

Skip

-----Original Message-----
From: David E Jones [mailto:jonesde@hotwaxmedia.com]
Sent: Thursday, October 04, 2007 6:21 PM
To: user@ofbiz.apache.org
Subject: Re: availableToPromiseTotal

Most retailers don't consider an add to cart to be sufficient
commitment on the customer's part to even try to guarantee that they
will get it. I have actually done stuff like that before, but I
really wouldn't recommend it because you end up with lots of funny
exceptions and it is too easy for data to get in bad states, or for
reservations to never get cleaned up and such. This also puts a lot
of traffic on certain entities too and can increase chances of
locking and other concurrency problems.

If you DO want to do this, I would recommend NOT using the current
availableToPromise counts and the OrderItemShipGrpInvRes records as
those are meant for something a little different, and a little more
important to get write (ie reduce chances of interfering with it and
what what).

-David

On Oct 4, 2007, at 7:04 PM, skip@theDevers wrote:

> In my wonderings through the ofbiz code, I have noted that
> availableToPromiseTotal for items on an order is not reduced until
> createOrder is called.  I expected availableToPromiseTotal to be
> reduced
> (assuming there was any) when the "Add To Order" button was pressed.
>
> This means that if there are 10 people using your system and 5 want
> the same
> product which has 3 in stock, all 5 will show AOH=3 when they press
> Add to
> Order, but two will get their order rejected when the order is
> processed.
>
> This is easy enough to change, but I wondered why it was done this
> way in
> case I am missing something.
>
> Skip
>

Re: availableToPromiseTotal

Posted by David E Jones <jo...@hotwaxmedia.com>.

Most retailers don't consider an add to cart to be sufficient  
commitment on the customer's part to even try to guarantee that they  
will get it. I have actually done stuff like that before, but I  
really wouldn't recommend it because you end up with lots of funny  
exceptions and it is too easy for data to get in bad states, or for  
reservations to never get cleaned up and such. This also puts a lot  
of traffic on certain entities too and can increase chances of  
locking and other concurrency problems.

If you DO want to do this, I would recommend NOT using the current  
availableToPromise counts and the OrderItemShipGrpInvRes records as  
those are meant for something a little different, and a little more  
important to get write (ie reduce chances of interfering with it and  
what what).

-David

On Oct 4, 2007, at 7:04 PM, skip@theDevers wrote:

> In my wonderings through the ofbiz code, I have noted that
> availableToPromiseTotal for items on an order is not reduced until
> createOrder is called.  I expected availableToPromiseTotal to be  
> reduced
> (assuming there was any) when the "Add To Order" button was pressed.
>
> This means that if there are 10 people using your system and 5 want  
> the same
> product which has 3 in stock, all 5 will show AOH=3 when they press  
> Add to
> Order, but two will get their order rejected when the order is  
> processed.
>
> This is easy enough to change, but I wondered why it was done this  
> way in
> case I am missing something.
>
> Skip
>

availableToPromiseTotal

Posted by "skip@theDevers" <sk...@thedevers.org>.

In my wonderings through the ofbiz code, I have noted that
availableToPromiseTotal for items on an order is not reduced until
createOrder is called.  I expected availableToPromiseTotal to be reduced
(assuming there was any) when the "Add To Order" button was pressed.

This means that if there are 10 people using your system and 5 want the same
product which has 3 in stock, all 5 will show AOH=3 when they press Add to
Order, but two will get their order rejected when the order is processed.

This is easy enough to change, but I wondered why it was done this way in
case I am missing something.

Skip

RE: CRM - Customer Relationship Management facilities in OFBiz

Posted by Philip Laing <ph...@ascconsultants.com.au>.

Thanks Jonathon ... as per usual I have misunderstood the ramifications your
where alluding too.  Thanks for filling me in 

Cheers

Phil


> -----Original Message-----
> From: Jonathon -- Improov [mailto:jonw@improov.com]
> Sent: Friday, 5 October 2007 1:02 AM
> To: user@ofbiz.apache.org
> Subject: Re: CRM - Customer Relationship Management facilities in OFBiz
> 
> Hi Philip,
> 
> Thanks for the insights regarding Java and Javascript. I know they are not
> the same.
> 
> Just a correction to something I wrote, by the way. Javascript isn't as
> fast as C/C++. The engine
> that interprets and runs Javascript is probably built with C/C++. But
> Javascript itself is an
> interpreted language. Java is half-interpreted (or half-compiled or half-
> digested). I would expect
> Java to be faster than Javascript.
> 
>  > Java is equally as powerful as C or C++ and is NOT a client side
>  > scripting that depends on a client computer for processing and does
>  > not need anything activated in the web browser to run.
> 
> Java is simply a language. Just as a server-client app can be coded
> entirely in C/C++, so can it
> be done in Java. OFBiz framework is done in Java.
> 
> The way Skip was using Java, it was a client side component.
> 
> Java's mechanisms for object-oriented programming is as robust, and
> certainly as "reference", as
> C/C++. Schools usually use Java to teach object-oriented concepts.
> 
>  > Java and JavaScript are commonly mistaken as somehow related to each
>  > other however this is not true
> 
> What did I say that made you think I mistook them to be related or even
> remotely similar? :)
> 
> By the way, Javascript does allow some form of object-oriented
> programming. Check out Dojo. So,
> when considering candidates for client side components, Javascript can be
> almost as attractive as
> Java for the reasons I mentioned (browser support, browser development for
> various platforms, etc).
> 
> Jonathon
> 
> Philip Laing wrote:
> > Hi Jonathon
> > JavaScript is entirely unassimilated with Java ... They are two separate
> > programming languages with two different origins.  JavaScript is
> entirely
> > client side browser scripting and Java is an entire programming language
> > which is similar to C syntax, although with similar names and similar
> > syntax.
> >
> > "JavaScript was originally developed by Brendan Eich of Netscape under
> the
> > name Mocha, later LiveScript, and finally renamed to JavaScript. The
> change
> > of name from LiveScript to JavaScript roughly coincided with Netscape
> adding
> > support for Java technology in its Netscape Navigator web browser." -
> > http://en.wikipedia.org/wiki/Javascript#History_and_naming
> >
> > "The Java language was created by James Gosling in June 1991 for use in
> a
> > set top box project. The language was initially called Oak, after an oak
> > tree that stood outside Gosling's office - and also went by the name
> Green -
> > and ended up later being renamed to Java, from a list of random words.
> > Gosling's goals were to implement a virtual machine and a language that
> had
> > a familiar C/C++ style of notation"
> > http://en.wikipedia.org/wiki/Java_%28programming_language%29#History
> >
> > Java is equally as powerful as C or C++ and is NOT a client side
> scripting
> > that depends on a client computer for processing and does not need
> anything
> > activated in the web browser to run.
> >
> > JavaServer Pages (JSPs) are server-side Java EE components that generate
> > responses, typically HTML pages, to HTTP requests from clients much the
> same
> > as ASP
> >
> > Java and JavaScript are commonly mistaken as somehow related to each
> other
> > however this is not true
> >
> > cheers
> >
> >
> > Phil
> >
> >
> >> -----Original Message-----
> >> From: Jonathon -- Improov [mailto:jonw@improov.com]
> >> Sent: Thursday, 4 October 2007 5:06 PM
> >> To: user@ofbiz.apache.org
> >> Subject: Re: CRM - Customer Relationship Management facilities in OFBiz
> >>
> >> Compiere has a similar "auto-deploy" mechanism. So that solves the
> >> "deploy" issue. There's still
> >> the issue of creating and maintaining 2 separate UI modules: one for
> Java
> >> app, the other for browser.
> >>
> >> Which reminds me. OFBiz browser UIs don't care about the case where
> >> javascript is disabled.
> >> Anyway, javascript can be selectively enabled (in the browser) for
> sites
> >> that the end-user trusts.
> >> The only place where this could be a problem is in the ecommmerce side,
> >> the public-facing end. In
> >> backoffice UIs, it's to mandate javascript.
> >>
> >> Jonathon
> >>
> >> Raj Saini wrote:
> >>>> I was thinking more in terms of IT department savings. The
> >>>> "create/maintain/deploy" human activities can be quite a bit more
> >>>> expensive (IT consultants) than backoffice personnel, I would think.
> >>>> Is that the case where you are?
> >>>>
> >>> With the new update technologies, I don't think this is a issue now.
> >>> Take example how Firefox updates itself without going through the pain
> >>> of manual deployment. Eclipse RCP has similar update manager, which is
> >>> used by Eclipse RCP based applications for auto update the new
> releases.
> >>>
> >>> Thanks,
> >>>
> >>> Raj
> >>>
> >>>
> >>>
> >
> >

Re: CRM - Customer Relationship Management facilities in OFBiz

Posted by Jonathon -- Improov <jo...@improov.com>.

Hi Philip,

Thanks for the insights regarding Java and Javascript. I know they are not the same.

Just a correction to something I wrote, by the way. Javascript isn't as fast as C/C++. The engine 
that interprets and runs Javascript is probably built with C/C++. But Javascript itself is an 
interpreted language. Java is half-interpreted (or half-compiled or half-digested). I would expect 
Java to be faster than Javascript.

 > Java is equally as powerful as C or C++ and is NOT a client side
 > scripting that depends on a client computer for processing and does
 > not need anything activated in the web browser to run.

Java is simply a language. Just as a server-client app can be coded entirely in C/C++, so can it 
be done in Java. OFBiz framework is done in Java.

The way Skip was using Java, it was a client side component.

Java's mechanisms for object-oriented programming is as robust, and certainly as "reference", as 
C/C++. Schools usually use Java to teach object-oriented concepts.

 > Java and JavaScript are commonly mistaken as somehow related to each
 > other however this is not true

What did I say that made you think I mistook them to be related or even remotely similar? :)

By the way, Javascript does allow some form of object-oriented programming. Check out Dojo. So, 
when considering candidates for client side components, Javascript can be almost as attractive as 
Java for the reasons I mentioned (browser support, browser development for various platforms, etc).

Jonathon

Philip Laing wrote:
> Hi Jonathon
> JavaScript is entirely unassimilated with Java ... They are two separate
> programming languages with two different origins.  JavaScript is entirely
> client side browser scripting and Java is an entire programming language
> which is similar to C syntax, although with similar names and similar
> syntax.
> 
> "JavaScript was originally developed by Brendan Eich of Netscape under the
> name Mocha, later LiveScript, and finally renamed to JavaScript. The change
> of name from LiveScript to JavaScript roughly coincided with Netscape adding
> support for Java technology in its Netscape Navigator web browser." -
> http://en.wikipedia.org/wiki/Javascript#History_and_naming 
> 
> "The Java language was created by James Gosling in June 1991 for use in a
> set top box project. The language was initially called Oak, after an oak
> tree that stood outside Gosling's office - and also went by the name Green -
> and ended up later being renamed to Java, from a list of random words.
> Gosling's goals were to implement a virtual machine and a language that had
> a familiar C/C++ style of notation"
> http://en.wikipedia.org/wiki/Java_%28programming_language%29#History
> 
> Java is equally as powerful as C or C++ and is NOT a client side scripting
> that depends on a client computer for processing and does not need anything
> activated in the web browser to run.
> 
> JavaServer Pages (JSPs) are server-side Java EE components that generate
> responses, typically HTML pages, to HTTP requests from clients much the same
> as ASP
> 
> Java and JavaScript are commonly mistaken as somehow related to each other
> however this is not true
> 
> cheers
> 
> 
> Phil 
> 
> 
>> -----Original Message-----
>> From: Jonathon -- Improov [mailto:jonw@improov.com]
>> Sent: Thursday, 4 October 2007 5:06 PM
>> To: user@ofbiz.apache.org
>> Subject: Re: CRM - Customer Relationship Management facilities in OFBiz
>>
>> Compiere has a similar "auto-deploy" mechanism. So that solves the
>> "deploy" issue. There's still
>> the issue of creating and maintaining 2 separate UI modules: one for Java
>> app, the other for browser.
>>
>> Which reminds me. OFBiz browser UIs don't care about the case where
>> javascript is disabled.
>> Anyway, javascript can be selectively enabled (in the browser) for sites
>> that the end-user trusts.
>> The only place where this could be a problem is in the ecommmerce side,
>> the public-facing end. In
>> backoffice UIs, it's to mandate javascript.
>>
>> Jonathon
>>
>> Raj Saini wrote:
>>>> I was thinking more in terms of IT department savings. The
>>>> "create/maintain/deploy" human activities can be quite a bit more
>>>> expensive (IT consultants) than backoffice personnel, I would think.
>>>> Is that the case where you are?
>>>>
>>> With the new update technologies, I don't think this is a issue now.
>>> Take example how Firefox updates itself without going through the pain
>>> of manual deployment. Eclipse RCP has similar update manager, which is
>>> used by Eclipse RCP based applications for auto update the new releases.
>>>
>>> Thanks,
>>>
>>> Raj
>>>
>>>
>>>
> 
>

RE: CRM - Customer Relationship Management facilities in OFBiz

Posted by Philip Laing <ph...@ascconsultants.com.au>.

Hi Jonathon
JavaScript is entirely unassimilated with Java ... They are two separate
programming languages with two different origins.  JavaScript is entirely
client side browser scripting and Java is an entire programming language
which is similar to C syntax, although with similar names and similar
syntax.

"JavaScript was originally developed by Brendan Eich of Netscape under the
name Mocha, later LiveScript, and finally renamed to JavaScript. The change
of name from LiveScript to JavaScript roughly coincided with Netscape adding
support for Java technology in its Netscape Navigator web browser." -
http://en.wikipedia.org/wiki/Javascript#History_and_naming 

"The Java language was created by James Gosling in June 1991 for use in a
set top box project. The language was initially called Oak, after an oak
tree that stood outside Gosling's office - and also went by the name Green -
and ended up later being renamed to Java, from a list of random words.
Gosling's goals were to implement a virtual machine and a language that had
a familiar C/C++ style of notation"
http://en.wikipedia.org/wiki/Java_%28programming_language%29#History

Java is equally as powerful as C or C++ and is NOT a client side scripting
that depends on a client computer for processing and does not need anything
activated in the web browser to run.

JavaServer Pages (JSPs) are server-side Java EE components that generate
responses, typically HTML pages, to HTTP requests from clients much the same
as ASP

Java and JavaScript are commonly mistaken as somehow related to each other
however this is not true

cheers

Phil 

> -----Original Message-----
> From: Jonathon -- Improov [mailto:jonw@improov.com]
> Sent: Thursday, 4 October 2007 5:06 PM
> To: user@ofbiz.apache.org
> Subject: Re: CRM - Customer Relationship Management facilities in OFBiz
> 
> Compiere has a similar "auto-deploy" mechanism. So that solves the
> "deploy" issue. There's still
> the issue of creating and maintaining 2 separate UI modules: one for Java
> app, the other for browser.
> 
> Which reminds me. OFBiz browser UIs don't care about the case where
> javascript is disabled.
> Anyway, javascript can be selectively enabled (in the browser) for sites
> that the end-user trusts.
> The only place where this could be a problem is in the ecommmerce side,
> the public-facing end. In
> backoffice UIs, it's to mandate javascript.
> 
> Jonathon
> 
> Raj Saini wrote:
> >
> >> I was thinking more in terms of IT department savings. The
> >> "create/maintain/deploy" human activities can be quite a bit more
> >> expensive (IT consultants) than backoffice personnel, I would think.
> >> Is that the case where you are?
> >>
> > With the new update technologies, I don't think this is a issue now.
> > Take example how Firefox updates itself without going through the pain
> > of manual deployment. Eclipse RCP has similar update manager, which is
> > used by Eclipse RCP based applications for auto update the new releases.
> >
> > Thanks,
> >
> > Raj
> >
> >
> >

Re: CRM - Customer Relationship Management facilities in OFBiz

Posted by Jonathon -- Improov <jo...@improov.com>.

Compiere has a similar "auto-deploy" mechanism. So that solves the "deploy" issue. There's still 
the issue of creating and maintaining 2 separate UI modules: one for Java app, the other for browser.

Which reminds me. OFBiz browser UIs don't care about the case where javascript is disabled. 
Anyway, javascript can be selectively enabled (in the browser) for sites that the end-user trusts. 
The only place where this could be a problem is in the ecommmerce side, the public-facing end. In 
backoffice UIs, it's to mandate javascript.

Jonathon

Raj Saini wrote:
> 
>> I was thinking more in terms of IT department savings. The 
>> "create/maintain/deploy" human activities can be quite a bit more 
>> expensive (IT consultants) than backoffice personnel, I would think. 
>> Is that the case where you are?
>>
> With the new update technologies, I don't think this is a issue now. 
> Take example how Firefox updates itself without going through the pain 
> of manual deployment. Eclipse RCP has similar update manager, which is 
> used by Eclipse RCP based applications for auto update the new releases.
> 
> Thanks,
> 
> Raj
> 
> 
>

Re: CRM - Customer Relationship Management facilities in OFBiz

Posted by Raj Saini <ra...@gmail.com>.

> I was thinking more in terms of IT department savings. The 
> "create/maintain/deploy" human activities can be quite a bit more 
> expensive (IT consultants) than backoffice personnel, I would think. 
> Is that the case where you are?
>
With the new update technologies, I don't think this is a issue now. 
Take example how Firefox updates itself without going through the pain 
of manual deployment. Eclipse RCP has similar update manager, which is 
used by Eclipse RCP based applications for auto update the new releases.

Thanks,

Raj

Re: CRM - Customer Relationship Management facilities in OFBiz

Posted by Jonathon -- Improov <jo...@improov.com>.

Skip,

I agree that it really depends on the customer's needs.

Perhaps in your case, the customer absolutely wants a blazing fast GUI, and doesn't want a browser 
UI at all. In that case, you'll really only be maintaining one set of GUI codes, the Java GUI app.

All my customers so far want to access OFBiz from "anywhere around the world". So that's a 
different case.

 > What is an issue to me is that not only the GUI code, but the Ofbiz Entity
 > Engine code as well is run on the client desktop

I think that's neat. It's still the same Entity Engine, one set of codes to maintain.

Is it that slow? Well, I believe it certainly is slower than raw SQL. Plus, it's written in Java.

Another interesting setup could be this. Have a few load-balanced and clustered servers running 
the Entity Engine, and a single OFBiz server running everything else. Might improve performance. 
But I'm not sure, like I said, I'm always surprised when it comes to optimization work. Will need 
to do some actual measurements first. Is the Entity Engine the bottleneck in OFBiz?

The above setup will allow the rest of us browser UI users to still use browser UIs, and fire off 
requests to the "Entity Engine servers". What do you think?

 > I concede that centrally managed code is way better.  So much so that it
 > generally trumps other considerations.  However, from a certain point of
 > view, the client code is still centrally managed provided that any changes a
 > promptly propagated to the desktops.

Yeah, you're right. The key is to "match client code to server code", ie "these versions of client 
codes works with those versions of server codes". It's not tough to manage that in SVN. OFBiz's 
POS codes is one example.

 > Also, once a GUI is written, it does not (or should not) get changed much.
 > Otherwise, the users face significant retraining costs.

I'm seeing small additive changes very often. Customers want a couple of new fields every week! 
Also, they want to compact the UIs every now and then (driven by end-user feedback), and that will 
not incur retraining costs. Making the UI simpler and more intuitive to use won't incur retraining 
costs.

Those small changes are cheap to do if I just have to manage a single set of UI codes --- the 
browser UI codes. Customers almost always want to tweak the paint job on quite a regular basis if 
it doesn't cost too much to do so. The only thing stopping them is if I say "that field will cost 
you another $5000".

 > I don't view this a swing back.  It is no different in concept than a java
 > applet.  In fact, it could be implemented as an applet.  It's just that it
 > would be a BIG applet, so may as well be an application deployed on the
 > desktop.

No, it's not a swing back if you're still maintaining only a single set of UI codes --- the Java 
GUI app. If you've chosen to use Java (SWT or applet) for your UI, it's as good a choice as 
HTML/AJAX. Java/SWT and HTML/AJAX are merely UI toolkits, both equally viable (the latter less 
responsive).

Hey, back to the CRM thing. Isn't there a standard set of CRM features that the market wants to 
see? Should we do something like that?

Jonathon

skip@theDevers wrote:
> Jonathon
> 
> I agree, nice discussion.
> 
> On point one, I agree, IT folks cost way more.  But, you make a value
> judgement at the outset.  If you are writing an application that will be
> used by one to save $3000; not a good idea.  But, if it will be used by 5
> and takes you two months, great ROI.
> 
> As you know, know, java byte code is JIT compiled to the local machine and
> in my testing is about 20% slower than raw C++.  Way better than interpreted
> Javascript.  But, I concede, on modern machines, it is not an issue.  What
> is an issue to me is that not only the GUI code, but the Ofbiz Entity Engine
> code as well is run on the client desktop.  Only the database server runs
> elsewhere.
> 
> I concede that centrally managed code is way better.  So much so that it
> generally trumps other considerations.  However, from a certain point of
> view, the client code is still centrally managed provided that any changes a
> promptly propagated to the desktops.
> 
> Also, once a GUI is written, it does not (or should not) get changed much.
> Otherwise, the users face significant retraining costs.
> 
> "While a full Java app is fast enough for trigger-happy trigger-efficient
> backoffice personnel, it
> might be too expensive a swing in the pendulum. Yes, end-users did suffer
> when we swung from
> user-friendliness to IT savings. But should we now swing so vehemently back
> to user-friendliness
> (with Java client app), and move so far away from IT savings?"
> 
> I don't view this a swing back.  It is no different in concept than a java
> applet.  In fact, it could be implemented as an applet.  It's just that it
> would be a BIG applet, so may as well be an application deployed on the
> desktop.
> 
> Also, I don't work for a particular company.  I would expect my work to be
> used by many, so the ROI increases with each installation.
> 
> I see room for both methods depending on the customers' needs.
> 
> Skip
> 
> -----Original Message-----
> From: Jonathon -- Improov [mailto:jonw@improov.com]
> Sent: Wednesday, October 03, 2007 11:25 PM
> To: user@ofbiz.apache.org
> Subject: Re: CRM - Customer Relationship Management facilities in OFBiz
> 
> 
> Hey Skip,
> 
> Nice discussion. :)
> 
>  > 1.  Backoffice personell are expensive.
> 
> I was thinking more in terms of IT department savings. The
> "create/maintain/deploy" human
> activities can be quite a bit more expensive (IT consultants) than
> backoffice personnel, I would
> think. Is that the case where you are?
> 
> Still, saving manpower is always good. AJAX (and Web 2.0) technology came in
> to correct the
> pendulum swing, the swing from saving backoffice manpower (or end-users) to
> saving IT manpower.
> Yes, usability and end-user experience did suffer when the IT folks tried to
> save on the
> "create/maintain/deploy" side of things.
> 
>  > It takes 20 seconds less on simple orders (Finalize with defaults) and 45
>  > seconds less with complicated ones using the Java app.
> 
> I had similar savings with AJAX. It's not so bad, really. After all, AJAX is
> done with javascript,
> and javascript is done with...? C/C++ or something similarly tight. The
> parser and runtime is in
> the browser itself! Now, where does Java stand in comparison? :)
> 
> I would imagine that your Java GUI app does trim and quick server calls (for
> quick
> synchronization) to the server. That's what AJAX does too.
> 
>  > I know I can achieve the same effect with ajax, but if I have to write
> these
>  > apps from scratch anyway, why not take advantage of the extra horsepower
> and
>  > compiled Java?
> 
> Because AJAX is still part of "server codes" (served up by server), so you
> can manage them
> centrally. Java client codes (GUI mostly?) is separated from server codes
> (separately installed on
> client). AJAX is coded as part of HTML pages served up by "server codes".
> 
> While a full Java app is fast enough for trigger-happy trigger-efficient
> backoffice personnel, it
> might be too expensive a swing in the pendulum. Yes, end-users did suffer
> when we swung from
> user-friendliness to IT savings. But should we now swing so vehemently back
> to user-friendliness
> (with Java client app), and move so far away from IT savings?
> 
>  > With Ofbiz code doing the grunt work, I can spend my time making the GUI
>  > fast, easy, and smart.
> 
> Actually, that business model does work. GUI is everything to customers or
> end-users. Some
> customers will pay a lot just to have GUIs they like. However, most
> customers I know are
> cost-conscious, and won't want to pay for a Porsche paint job if they can
> get a cheaper and still
> effective GUI that works.
> 
> If your customer is willing to pay lots for future maintenance of Java GUI
> app, browser GUI
> modules (OFBiz widgets and such), and OFBiz backend modules, then sure, have
> fun doing all that
> maintenance.
> 
> Eg scenario: "Did you change the UI like I wanted?"... "Yes, I did"... "I
> see it only in the
> browser GUI modules"... "I'll do it in the Java GUI module too, sorry I
> forgot"... "Make sure you
> do the change exactly, I want the change to be precisely uniform and
> consistent".
> 
>  > 2.  "Also, the move forward is to "dumb down" the client terminals (cheap
> to
>  > deploy, scalable)."... Witness the move to Ajax backed Javascript as an
>  > example.
> 
> "Dumbing down" client terminals means we don't have to "teach" (install)
> those terminals too much.
> The point is to be able to acquire any computer (new or old), and still be
> able to run the app and
> hit the server, without having to "teach" or install much to those
> terminals.
> 
> AJAX is part of the browser. Browser adoption rates are driven by browser
> competition, not by our
> own Java GUI development team. With browser adoption moving along healthily,
> we can do away with
> our Java GUI development team (reassign).
> 
>  > It takes almost no time to code a GUI with Netbeans.
> 
> In software development, the biggest headaches isn't about getting something
> coded. It's about
> collaboration between IT teams, collaboration between software components
> (in your case, server
> and client components). And the need for such collaboration is so strong,
> version control
> mechanisms were born, and honed by now.
> 
> Take this DocBook example (since there was a recent mention of DocBooks
> somewhere). DocBook is
> plain text format, and can be automatically converted into OpenDocument
> format (MS Word equivalent
> in OpenOffice). OpenDocument format is binary. Suppose I write a huge book
> using OpenDocument
> format, and I make some changes. I would have to send a new complete binary
> of the whole book to
> my publisher. But with DocBook's plain text format, plus version control, I
> only need to send a
> small diff to update (collaborate with) my publisher.
> 
> More than 10 years back, I remember a time when we used MS Word documents
> for functional specs.
> Lots of protocols then for change management, under project management. For
> every change in the
> specs documents, a "changelog" section needs to be carefully and
> painstakingly updated. In
> reality, there were many "carefully and painstakingly" crafted errors in
> those "changelog"
> sections. We're just humans. There was simply no way to do a "diff" for MS
> Word docs.
> 
>  > No such tools currently exist (that I know of) for Ajax backed apps.
> 
> It may take some time for AJAX frameworks to compete and crystallize some
> standards. Or has that
> already happened? Still, it isn't difficult to do AJAX. It's almost standard
> by now.
> 
>  > 4.  "In production, servers aren't hit all the time. There are peak
> periods,
>  > and there are lull periods."  If the brains are on the user's desktop,
> there
>  > are no lull or peaks at any time (and no associated aggravation).  Their
>  > work is never interrupted or slowed (assuming the database server is not
>  > overloaded.)
> 
> Even if you put the Java GUI app on the client terminals, you'll still need
> to handle peak periods
> on the server codes. If you're already doing clustering and load-balancing
> on the server side, you
> might as well do it there only, and gain the benefit of "easier control"
> (only a few servers,
> platforms and setups you can control).
> 
> If you're thinking of executing business logic codes on the client
> terminals, you face the
> additional risk of such codes running differently on different terminals. We
> never know. Sun SDK
> could run a tad different on some setups. There'd be so many different
> setups or platforms to
> cater for, the cost of maintenance could increase exponentially.
> 
> To fix that problem, you could mandate a uniform setup for all client
> terminals. So, if the top
> boss wants a newfangled 128-bit computer, and still wants to run your Java
> GUI app, would you be
> able to tell him "Sir, you gotta get with the program because Sun SDK won't
> run with 128-bit"? :)
> 
> Using only browsers as the client app, the responsibility to "cater for
> various platforms" falls
> on the browser developers instead.
> 
>  > 5.  "Those folks writing the "offloading algorithms" won't know how
> fast/slow
>  > my computer is."  Gads Jonathon, I couldnt agree more.  I get aggravated
>  > daily waiting for Javascript intensive web pages to download.  However, I
> am
>  > not running javascript, but blazingly fast compiled Java.  If the user's
>  > machine doesnt have the guts, I wouldn't install Ofbiz on it.  They can
> use a
>  > browser to access the same funcionality.
> 
> Then you'd have double the maintenance responsibility.
> 
> You not only have to maintain the server codes that servers up GUI via
> browser, you also have to
> maintain the Java GUI app.
> 
> Finally, you may argue that javascript is just too difficult to handle (I
> hate it too). Browsers
> might deal with javascript so differently (or even wrongly at times). You
> could consider mandating
> that every dumb terminal installs a new browser (the winner then). The best
> browser out there will
> be a cinch to install. There's ready support for the browser. Many great
> browsers are now free,
> even opensource. Will your Java GUI app be able to compete with the polish
> that goes into browser
> development and support?
> 
> Jonathon
> 
> skip@theDevers wrote:
>> Johathon
>>
>> Hmmm, you've almost got me convinced to give this up.  So convinced in
> fact
>> that I am gonna forward this email on to my current customer and get his
>> reaction.  It's well thought out and you obviously spent a great deal of
>> time thinking about it and I thank you for it lavishly.
>>
>> Still, I have these arguments in favor to offer:
>>
>> 1.  Backoffice personell are expensive.  Even saving them 10 minutes
> (that's
>> 10 seconds a transaction or less) a day translates to $3000 a year even
> for
>> the lower paid ones, and this is per-person.  I have timed myself using
> the
>> Ofbiz "Order Entry" screen to enter a two item sale and the desktop Java
>> based order entry application I am currently finishing.  The results?  It
>> takes 20 seconds less on simple orders (Finalize with defaults) and 45
>> seconds less with complicated ones using the Java app. And, all my code is
>> using the stock Ofbiz services to do the real work so it's fairly simple
> to
>> write.  The difference in time is because I can change the control having
>> the input focus intelligently and I don't have to wait for brower repaints
>> between atomic operations.  A fast operator can go as fast as they can
> type.
>> I know I can achieve the same effect with ajax, but if I have to write
> these
>> apps from scratch anyway, why not take advantage of the extra horsepower
> and
>> compiled Java?  By the way, the nearly finished Java app is surprisingly
>> small.  With Ofbiz code doing the grunt work, I can spend my time making
> the
>> GUI fast, easy, and smart.
>>
>> 2.  "Also, the move forward is to "dumb down" the client terminals (cheap
> to
>> deploy, scalable)."  I would partially disagree with this although it is
>> repeated a lot.  This was certainly true a couple of years ago, but
> lately,
>> we are heading back in the other direction.  Witness the move to Ajax
> backed
>> Javascript as an example. It takes almost no time to code a GUI with
>> Netbeans.  No such tools currently exist (that I know of) for Ajax backed
>> apps.  Also. go look at the sales stats for Dell and HP and you will see
>> that the  majority of their sales are to business and it shows no signs of
>> slowing (although it is not increasing as fast as it was a few years ago).
>>
>> 3.  "Even if the client terminals just happen to be blazing fast enough
> for
>> graphics-intensive work...".  Graphics-intensive capability is more a
> factor
>> of the video card than the CPU.  EVERY desktop I see with an A/R or A/P
>> person in the chair is capable of running Ofbiz, Word and Excel at the
> same
>> time.  On my test box, I have Ofbiz running with Netbeans, Visual Studio,
>> Gaim, and Outlook and it's no smoker and joker.
>>
>> 4.  "In production, servers aren't hit all the time. There are peak
> periods,
>> and there are lull periods."  If the brains are on the user's desktop,
> there
>> are no lull or peaks at any time (and no associated aggravation).  Their
>> work is never interrupted or slowed (assuming the database server is not
>> overloaded.)
>>
>>
>> 5.  "Those folks writing the "offloading algorithms" won't know how
>> fast/slow my computer is."  Gads Jonathon, I couldnt agree more.  I get
>> aggravated daily waiting for Javascript intensive web pages to download.
>> However, I am not running javascript, but blazingly fast compiled Java.
> If
>> the user's machine doesnt have the guts, I wouldn't install Ofbiz on it.
>> They can use a browser to access the same funcionality.
>>
>>
>> Hmmm, now I've almost convinced myself to carry on. :)
>>
>> Cheers
>>
>> Skip
>>
>>
>> -----Original Message-----
>> From: Jonathon -- Improov [mailto:jonw@improov.com]
>> Sent: Wednesday, October 03, 2007 7:43 PM
>> To: user@ofbiz.apache.org
>> Subject: Re: CRM - Customer Relationship Management facilities in OFBiz
>>
>>
>>  > You might be surprised by how expensive such a solution would be to
>>  > create/maintain/deploy and how little it will help on server resources.
>>
>> I have many clients wanting to move away from that distributed (client
>> codes) model to the
>> centralized (server codes) model. Yes, it is proving to be expensive.
> Kinda
>> "tried and tested" to
>> be expensive, actually.
>>
>> "Create/maintain/deploy" are all human activities. Will be inordinately
>> expensive to create
>> artificial intelligence to do all that. In general (with our current
>> state-of-the-art of AI), it
>> is cheaper to simply upgrade the server hardware. Yes, computer hardware
>> speed improvement may be
>> slowing down now (used to be doubling every 1.5 years?). But there will
>> surely be something new
>> coming up (quantum computers, multi-state logic units, etc), unless we're
>> suddenly hit by an
>> epidemic that halves human intelligence every 1.5 years. (Or I infect all
>> you guys with my stupidity).
>>
>> Also, the move forward is to "dumb down" the client terminals (cheap to
>> deploy, scalable). Even if
>> the client terminals just happen to be blazing fast enough for
>> graphics-intensive work, perhaps
>> those terminals' users' job scope is to do graphics-intensive work on a
>> regular basis? Putting a
>> part of OFBiz into those machines will compromise the efficiency of their
>> graphics-intensive work.
>>
>> As for "You might be surprised", I'm ALWAYS surprised when it comes to
> doing
>> optimization work!
>> Optimization needs are very hard to calculate and predict by hand. Rather
>> than spend weeks using
>> complex maths and theories to predict (presume, rather) bottle-necks, it's
>> easier to spend a
>> couple of hours to do an actual measurement of computation speeds.
>>
>>  > You might also be surprised by how capable servers are of handling
>>  > concurrent load, how different performance tends to be in a development
>>  > versus production environment, and for certain things how easy it is to
>>  > tune them once the slowest stuff has been identified.
>>
>> In production, servers aren't hit all the time. There are peak periods,
> and
>> there are lull
>> periods. To handle such cases, clustering and load-balancing is the usual
>> practice. The diff
>> between clustering servers and using smart client terminals, both being
>> distributed models, is
>> this... it's easier to monitor and tune a few servers than to do so for
>> hundreds of client terminals.
>>
>> Also, consider how irritating javascript is getting to be, those that try
> to
>> offload huge amounts
>> of servers' workloads into our personal computers. Those folks writing the
>> "offloading algorithms"
>> won't know how fast/slow my computer is, and could render my computer
>> completely useless by
>> overloading it.
>>
>> But before going into clustering, it is often adequate to spot the
>> bottle-necks in a single
>> server, and optimize just those areas. That'll help the OFBiz framework
> and
>> help the OFBiz
>> community too.
>>
>> For all the optimization smarts we have, I must say that I had
>> over-optimized before in my career.
>> In business, over-optimizing a system isn't "passing with flying colors",
>> but actually translates
>> into a loss. While it is great to "push the envelope", it'll help in
> thesis
>> writing more than in
>> business. Study the bottle-necks in production settings, and fix just
> those.
>> Still, please feel free to over-optimize the OFBiz framework! That's a
>> different scenario. Huge ROI.
>>
>> Jonathon
>>
>> David E Jones wrote:
>>> You might be surprised by how expensive such a solution would be to
>>> create/maintain/deploy and how little it will help on server resources.
>>> You might also be surprised by how capable servers are of handling
>>> concurrent load, how different performance tends to be in a development
>>> versus production environment, and for certain things how easy it is to
>>> tune them once the slowest stuff has been identified.
>>>
>>> -David
>>>
>>>
>>> On Oct 3, 2007, at 1:05 PM, skip@theDevers wrote:
>>>
>>>> David
>>>>
>>>> This issue here to me asset utilization.  In a typical mid-sized
> company,
>>>> there are dozens or hundreds of desktop computers that their user use
>>>> to do
>>>> their daily work.  If the user is using a browser to access logic on
>>>> one of
>>>> Ofbiz servers, the desktop is under-utilized.  By tying in a desktop
>>>> application to Ofbiz (i.e. running an entity engine on the desktop
>>>> tied to
>>>> the same database as the main ofbiz servers and running xml setups
>>>> identical
>>>> to the servers), that workload is performed on the users desktop and
>>>> not on
>>>> the main ofbiz servers thereby freeing the server for functionality that
>>>> REQUIRES browser based access.
>>>>
>>>> This does not in any way supplant Ofbiz, it enhances it by
>>>> distributing the
>>>> workload and giving the clerical user a better amd more responsive
>>>> experience.
>>>>
>>>> As some examples, my recent testing of the sales order functionality
>>>> shows
>>>> that it takes ~ 200 msecs to complete the "userLogin" service or 120
>>>> msecs
>>>> to complete "calculateProductPrice" (these numbers are from the ofbiz
> log
>>>> file on a fairly fast machine with lots of debug output).  If this is
> all
>>>> done on the main ofbiz servers about 5 of the former and 10 of the
>>>> later can
>>>> be done simultaneously to maintain a reasonable lag time.  If the load
> is
>>>> spread out among say 8 desktops and 2 browser accesses, everyone has a
>>>> really good experience.
>>>>
>>>> The only drawback to this all is that if the server configuration
>>>> changes,
>>>> the desktops must be patched as well.  In practice, that is not a big
>>>> issue.
>>>>
>>>> So, it makes great sense to me to write desktop applications for common
>>>> backoffice functions.
>>>>
>>>> I am currently working on a suite of such applications, hence my
>>>> interest in
>>>> BJs SWT based CRM.
>>>>
>>>> Skip
>>>>
>>>> -----Original Message-----
>>>> From: David E Jones [mailto:jonesde@hotwaxmedia.com]
>>>> Sent: Wednesday, October 03, 2007 11:12 AM
>>>> To: user@ofbiz.apache.org
>>>> Subject: Re: CRM - Customer Relationship Management facilities in OFBiz
>>>>
>>>>
>>>>
>>>> I'm not sure where this thread is leading or how it's related to
>>>> OFBiz...
>>>>
>>>> In any case, there is CRM functionality in OFBiz. The first step
>>>> would be defining in a little more detail what you mean by "CRM"
>>>> since that means very different things in different companies. OFBiz
>>>> does offer a single view into customer interactions including web
>>>> site visits, phone/email/in-person/etc communications, requests,
>>>> quotes, orders, shipments, invoices, payments, balance accounts,
>>>> projects, calendar events, and many other things. You can also
>>>> classify parties for marketing and sales, and do things like
>>>> marketing campaigns including reference codes via email, snail mail,
>>>> whatever.
>>>>
>>>> If you're looking for simple desktop contact management something
>>>> like ACT or even salesforce.com would be better. If you're looking
>>>> for enterprise CRM (especially a business or industry specific
>>>> incarnation of such) then OFBiz a great basis for the effort.
>>>>
>>>> -David
>>>>
>>>>
>>>> On Oct 3, 2007, at 11:07 AM, skip@theDevers wrote:
>>>>
>>>>> I'd like to see the SWT code as it is.  To heck with translating it
>>>>> to use
>>>>> web based widgets.
>>>>>
>>>>> I gotta set up a web site soon to hold code like this.
>>>>>
>>>>> Skip
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: BJ Freeman [mailto:bjfree@free-man.net]
>>>>> Sent: Wednesday, October 03, 2007 3:06 AM
>>>>> To: user@ofbiz.apache.org
>>>>> Subject: Re: CRM - Customer Relationship Management facilities in
>>>>> OFBiz
>>>>>
>>>>>
>>>>> basically yes.
>>>>> the tool i used added some classes to better manage things.
>>>>> http://www.elance.com/p/?
>>>>> q=eolproviderprofile&view_person=BJFreeman&catid=10
>>>>> 182#tab=1
>>>>> click on Java CRM
>>>>>
>>>>> skip@theDevers sent the following on 10/2/2007 8:55 PM:
>>>>>> BJ
>>>>>>
>>>>>> SWT as in Eclipse SWT?
>>>>>>
>>>>>> Skip
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: BJ Freeman [mailto:bjfree@free-man.net]
>>>>>> Sent: Tuesday, October 02, 2007 8:26 PM
>>>>>> To: user@ofbiz.apache.org
>>>>>> Subject: Re: CRM - Customer Relationship Management facilities in
>>>>>> OFBiz
>>>>>>
>>>>>>
>>>>>> there at least two efforts going that i know of.
>>>>>> the data model pretty much has all that you need.
>>>>>> Si's implementation does not totally integrate with the current data
>>>>>> storage. it is built on ofbiz but is supported under opentaps.
>>>>>> Mine is something I am bringing over from Java SWT and SQL db.
>>>>>> Once I figure out how to show the UI I want in widgets I will release
>>>>>> it. Currently for my clients I use a java sWT that connects to ofbiz.
>>>>>> It is built entirely within the current ofbiz datamodel.
>>>>>> as soon as I get some irons of the fire will focus on it more
>>>>>>
>>>>>>
>>>>>>
>>>>>> Philip Laing sent the following on 10/2/2007 7:36 PM:
>>>>>>> Thanks for your input relating my previous questions, I am
>>>>>>> interested in
>>>>>>> implementing some sort of Helpdesk/CRM system and I am interested
>>>>>>> in what
>>>>>>> facilities OFBiz already has
>>>>>>>
>>>>>>> Thanks
>>>>>>> Phil
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>
>>
> 
> 
>

RE: CRM - Customer Relationship Management facilities in OFBiz

Posted by "skip@theDevers" <sk...@thedevers.org>.

Jonathon

I agree, nice discussion.

On point one, I agree, IT folks cost way more.  But, you make a value
judgement at the outset.  If you are writing an application that will be
used by one to save $3000; not a good idea.  But, if it will be used by 5
and takes you two months, great ROI.

As you know, know, java byte code is JIT compiled to the local machine and
in my testing is about 20% slower than raw C++.  Way better than interpreted
Javascript.  But, I concede, on modern machines, it is not an issue.  What
is an issue to me is that not only the GUI code, but the Ofbiz Entity Engine
code as well is run on the client desktop.  Only the database server runs
elsewhere.

I concede that centrally managed code is way better.  So much so that it
generally trumps other considerations.  However, from a certain point of
view, the client code is still centrally managed provided that any changes a
promptly propagated to the desktops.

Also, once a GUI is written, it does not (or should not) get changed much.
Otherwise, the users face significant retraining costs.

"While a full Java app is fast enough for trigger-happy trigger-efficient
backoffice personnel, it
might be too expensive a swing in the pendulum. Yes, end-users did suffer
when we swung from
user-friendliness to IT savings. But should we now swing so vehemently back
to user-friendliness
(with Java client app), and move so far away from IT savings?"

I don't view this a swing back.  It is no different in concept than a java
applet.  In fact, it could be implemented as an applet.  It's just that it
would be a BIG applet, so may as well be an application deployed on the
desktop.

Also, I don't work for a particular company.  I would expect my work to be
used by many, so the ROI increases with each installation.

I see room for both methods depending on the customers' needs.

Skip

-----Original Message-----
From: Jonathon -- Improov [mailto:jonw@improov.com]
Sent: Wednesday, October 03, 2007 11:25 PM
To: user@ofbiz.apache.org
Subject: Re: CRM - Customer Relationship Management facilities in OFBiz

Hey Skip,

Nice discussion. :)

 > 1.  Backoffice personell are expensive.

I was thinking more in terms of IT department savings. The
"create/maintain/deploy" human
activities can be quite a bit more expensive (IT consultants) than
backoffice personnel, I would
think. Is that the case where you are?

Still, saving manpower is always good. AJAX (and Web 2.0) technology came in
to correct the
pendulum swing, the swing from saving backoffice manpower (or end-users) to
saving IT manpower.
Yes, usability and end-user experience did suffer when the IT folks tried to
save on the
"create/maintain/deploy" side of things.

 > It takes 20 seconds less on simple orders (Finalize with defaults) and 45
 > seconds less with complicated ones using the Java app.

I had similar savings with AJAX. It's not so bad, really. After all, AJAX is
done with javascript,
and javascript is done with...? C/C++ or something similarly tight. The
parser and runtime is in
the browser itself! Now, where does Java stand in comparison? :)

I would imagine that your Java GUI app does trim and quick server calls (for
quick
synchronization) to the server. That's what AJAX does too.

 > I know I can achieve the same effect with ajax, but if I have to write
these
 > apps from scratch anyway, why not take advantage of the extra horsepower
and
 > compiled Java?

Because AJAX is still part of "server codes" (served up by server), so you
can manage them
centrally. Java client codes (GUI mostly?) is separated from server codes
(separately installed on
client). AJAX is coded as part of HTML pages served up by "server codes".

While a full Java app is fast enough for trigger-happy trigger-efficient
backoffice personnel, it
might be too expensive a swing in the pendulum. Yes, end-users did suffer
when we swung from
user-friendliness to IT savings. But should we now swing so vehemently back
to user-friendliness
(with Java client app), and move so far away from IT savings?

 > With Ofbiz code doing the grunt work, I can spend my time making the GUI
 > fast, easy, and smart.

Actually, that business model does work. GUI is everything to customers or
end-users. Some
customers will pay a lot just to have GUIs they like. However, most
customers I know are
cost-conscious, and won't want to pay for a Porsche paint job if they can
get a cheaper and still
effective GUI that works.

If your customer is willing to pay lots for future maintenance of Java GUI
app, browser GUI
modules (OFBiz widgets and such), and OFBiz backend modules, then sure, have
fun doing all that
maintenance.

Eg scenario: "Did you change the UI like I wanted?"... "Yes, I did"... "I
see it only in the
browser GUI modules"... "I'll do it in the Java GUI module too, sorry I
forgot"... "Make sure you
do the change exactly, I want the change to be precisely uniform and
consistent".

 > 2.  "Also, the move forward is to "dumb down" the client terminals (cheap
to
 > deploy, scalable)."... Witness the move to Ajax backed Javascript as an
 > example.

"Dumbing down" client terminals means we don't have to "teach" (install)
those terminals too much.
The point is to be able to acquire any computer (new or old), and still be
able to run the app and
hit the server, without having to "teach" or install much to those
terminals.

AJAX is part of the browser. Browser adoption rates are driven by browser
competition, not by our
own Java GUI development team. With browser adoption moving along healthily,
we can do away with
our Java GUI development team (reassign).

 > It takes almost no time to code a GUI with Netbeans.

In software development, the biggest headaches isn't about getting something
coded. It's about
collaboration between IT teams, collaboration between software components
(in your case, server
and client components). And the need for such collaboration is so strong,
version control
mechanisms were born, and honed by now.

Take this DocBook example (since there was a recent mention of DocBooks
somewhere). DocBook is
plain text format, and can be automatically converted into OpenDocument
format (MS Word equivalent
in OpenOffice). OpenDocument format is binary. Suppose I write a huge book
using OpenDocument
format, and I make some changes. I would have to send a new complete binary
of the whole book to
my publisher. But with DocBook's plain text format, plus version control, I
only need to send a
small diff to update (collaborate with) my publisher.

More than 10 years back, I remember a time when we used MS Word documents
for functional specs.
Lots of protocols then for change management, under project management. For
every change in the
specs documents, a "changelog" section needs to be carefully and
painstakingly updated. In
reality, there were many "carefully and painstakingly" crafted errors in
those "changelog"
sections. We're just humans. There was simply no way to do a "diff" for MS
Word docs.

 > No such tools currently exist (that I know of) for Ajax backed apps.

It may take some time for AJAX frameworks to compete and crystallize some
standards. Or has that
already happened? Still, it isn't difficult to do AJAX. It's almost standard
by now.

 > 4.  "In production, servers aren't hit all the time. There are peak
periods,
 > and there are lull periods."  If the brains are on the user's desktop,
there
 > are no lull or peaks at any time (and no associated aggravation).  Their
 > work is never interrupted or slowed (assuming the database server is not
 > overloaded.)

Even if you put the Java GUI app on the client terminals, you'll still need
to handle peak periods
on the server codes. If you're already doing clustering and load-balancing
on the server side, you
might as well do it there only, and gain the benefit of "easier control"
(only a few servers,
platforms and setups you can control).

If you're thinking of executing business logic codes on the client
terminals, you face the
additional risk of such codes running differently on different terminals. We
never know. Sun SDK
could run a tad different on some setups. There'd be so many different
setups or platforms to
cater for, the cost of maintenance could increase exponentially.

To fix that problem, you could mandate a uniform setup for all client
terminals. So, if the top
boss wants a newfangled 128-bit computer, and still wants to run your Java
GUI app, would you be
able to tell him "Sir, you gotta get with the program because Sun SDK won't
run with 128-bit"? :)

Using only browsers as the client app, the responsibility to "cater for
various platforms" falls
on the browser developers instead.

 > 5.  "Those folks writing the "offloading algorithms" won't know how
fast/slow
 > my computer is."  Gads Jonathon, I couldnt agree more.  I get aggravated
 > daily waiting for Javascript intensive web pages to download.  However, I
am
 > not running javascript, but blazingly fast compiled Java.  If the user's
 > machine doesnt have the guts, I wouldn't install Ofbiz on it.  They can
use a
 > browser to access the same funcionality.

Then you'd have double the maintenance responsibility.

You not only have to maintain the server codes that servers up GUI via
browser, you also have to
maintain the Java GUI app.

Finally, you may argue that javascript is just too difficult to handle (I
hate it too). Browsers
might deal with javascript so differently (or even wrongly at times). You
could consider mandating
that every dumb terminal installs a new browser (the winner then). The best
browser out there will
be a cinch to install. There's ready support for the browser. Many great
browsers are now free,
even opensource. Will your Java GUI app be able to compete with the polish
that goes into browser
development and support?

Jonathon

skip@theDevers wrote:
> Johathon
>
> Hmmm, you've almost got me convinced to give this up.  So convinced in
fact
> that I am gonna forward this email on to my current customer and get his
> reaction.  It's well thought out and you obviously spent a great deal of
> time thinking about it and I thank you for it lavishly.
>
> Still, I have these arguments in favor to offer:
>
> 1.  Backoffice personell are expensive.  Even saving them 10 minutes
(that's
> 10 seconds a transaction or less) a day translates to $3000 a year even
for
> the lower paid ones, and this is per-person.  I have timed myself using
the
> Ofbiz "Order Entry" screen to enter a two item sale and the desktop Java
> based order entry application I am currently finishing.  The results?  It
> takes 20 seconds less on simple orders (Finalize with defaults) and 45
> seconds less with complicated ones using the Java app. And, all my code is
> using the stock Ofbiz services to do the real work so it's fairly simple
to
> write.  The difference in time is because I can change the control having
> the input focus intelligently and I don't have to wait for brower repaints
> between atomic operations.  A fast operator can go as fast as they can
type.
> I know I can achieve the same effect with ajax, but if I have to write
these
> apps from scratch anyway, why not take advantage of the extra horsepower
and
> compiled Java?  By the way, the nearly finished Java app is surprisingly
> small.  With Ofbiz code doing the grunt work, I can spend my time making
the
> GUI fast, easy, and smart.
>
> 2.  "Also, the move forward is to "dumb down" the client terminals (cheap
to
> deploy, scalable)."  I would partially disagree with this although it is
> repeated a lot.  This was certainly true a couple of years ago, but
lately,
> we are heading back in the other direction.  Witness the move to Ajax
backed
> Javascript as an example. It takes almost no time to code a GUI with
> Netbeans.  No such tools currently exist (that I know of) for Ajax backed
> apps.  Also. go look at the sales stats for Dell and HP and you will see
> that the  majority of their sales are to business and it shows no signs of
> slowing (although it is not increasing as fast as it was a few years ago).
>
> 3.  "Even if the client terminals just happen to be blazing fast enough
for
> graphics-intensive work...".  Graphics-intensive capability is more a
factor
> of the video card than the CPU.  EVERY desktop I see with an A/R or A/P
> person in the chair is capable of running Ofbiz, Word and Excel at the
same
> time.  On my test box, I have Ofbiz running with Netbeans, Visual Studio,
> Gaim, and Outlook and it's no smoker and joker.
>
> 4.  "In production, servers aren't hit all the time. There are peak
periods,
> and there are lull periods."  If the brains are on the user's desktop,
there
> are no lull or peaks at any time (and no associated aggravation).  Their
> work is never interrupted or slowed (assuming the database server is not
> overloaded.)
>
>
> 5.  "Those folks writing the "offloading algorithms" won't know how
> fast/slow my computer is."  Gads Jonathon, I couldnt agree more.  I get
> aggravated daily waiting for Javascript intensive web pages to download.
> However, I am not running javascript, but blazingly fast compiled Java.
If
> the user's machine doesnt have the guts, I wouldn't install Ofbiz on it.
> They can use a browser to access the same funcionality.
>
>
> Hmmm, now I've almost convinced myself to carry on. :)
>
> Cheers
>
> Skip
>
>
> -----Original Message-----
> From: Jonathon -- Improov [mailto:jonw@improov.com]
> Sent: Wednesday, October 03, 2007 7:43 PM
> To: user@ofbiz.apache.org
> Subject: Re: CRM - Customer Relationship Management facilities in OFBiz
>
>
>  > You might be surprised by how expensive such a solution would be to
>  > create/maintain/deploy and how little it will help on server resources.
>
> I have many clients wanting to move away from that distributed (client
> codes) model to the
> centralized (server codes) model. Yes, it is proving to be expensive.
Kinda
> "tried and tested" to
> be expensive, actually.
>
> "Create/maintain/deploy" are all human activities. Will be inordinately
> expensive to create
> artificial intelligence to do all that. In general (with our current
> state-of-the-art of AI), it
> is cheaper to simply upgrade the server hardware. Yes, computer hardware
> speed improvement may be
> slowing down now (used to be doubling every 1.5 years?). But there will
> surely be something new
> coming up (quantum computers, multi-state logic units, etc), unless we're
> suddenly hit by an
> epidemic that halves human intelligence every 1.5 years. (Or I infect all
> you guys with my stupidity).
>
> Also, the move forward is to "dumb down" the client terminals (cheap to
> deploy, scalable). Even if
> the client terminals just happen to be blazing fast enough for
> graphics-intensive work, perhaps
> those terminals' users' job scope is to do graphics-intensive work on a
> regular basis? Putting a
> part of OFBiz into those machines will compromise the efficiency of their
> graphics-intensive work.
>
> As for "You might be surprised", I'm ALWAYS surprised when it comes to
doing
> optimization work!
> Optimization needs are very hard to calculate and predict by hand. Rather
> than spend weeks using
> complex maths and theories to predict (presume, rather) bottle-necks, it's
> easier to spend a
> couple of hours to do an actual measurement of computation speeds.
>
>  > You might also be surprised by how capable servers are of handling
>  > concurrent load, how different performance tends to be in a development
>  > versus production environment, and for certain things how easy it is to
>  > tune them once the slowest stuff has been identified.
>
> In production, servers aren't hit all the time. There are peak periods,
and
> there are lull
> periods. To handle such cases, clustering and load-balancing is the usual
> practice. The diff
> between clustering servers and using smart client terminals, both being
> distributed models, is
> this... it's easier to monitor and tune a few servers than to do so for
> hundreds of client terminals.
>
> Also, consider how irritating javascript is getting to be, those that try
to
> offload huge amounts
> of servers' workloads into our personal computers. Those folks writing the
> "offloading algorithms"
> won't know how fast/slow my computer is, and could render my computer
> completely useless by
> overloading it.
>
> But before going into clustering, it is often adequate to spot the
> bottle-necks in a single
> server, and optimize just those areas. That'll help the OFBiz framework
and
> help the OFBiz
> community too.
>
> For all the optimization smarts we have, I must say that I had
> over-optimized before in my career.
> In business, over-optimizing a system isn't "passing with flying colors",
> but actually translates
> into a loss. While it is great to "push the envelope", it'll help in
thesis
> writing more than in
> business. Study the bottle-necks in production settings, and fix just
those.
>
> Still, please feel free to over-optimize the OFBiz framework! That's a
> different scenario. Huge ROI.
>
> Jonathon
>
> David E Jones wrote:
>> You might be surprised by how expensive such a solution would be to
>> create/maintain/deploy and how little it will help on server resources.
>> You might also be surprised by how capable servers are of handling
>> concurrent load, how different performance tends to be in a development
>> versus production environment, and for certain things how easy it is to
>> tune them once the slowest stuff has been identified.
>>
>> -David
>>
>>
>> On Oct 3, 2007, at 1:05 PM, skip@theDevers wrote:
>>
>>> David
>>>
>>> This issue here to me asset utilization.  In a typical mid-sized
company,
>>> there are dozens or hundreds of desktop computers that their user use
>>> to do
>>> their daily work.  If the user is using a browser to access logic on
>>> one of
>>> Ofbiz servers, the desktop is under-utilized.  By tying in a desktop
>>> application to Ofbiz (i.e. running an entity engine on the desktop
>>> tied to
>>> the same database as the main ofbiz servers and running xml setups
>>> identical
>>> to the servers), that workload is performed on the users desktop and
>>> not on
>>> the main ofbiz servers thereby freeing the server for functionality that
>>> REQUIRES browser based access.
>>>
>>> This does not in any way supplant Ofbiz, it enhances it by
>>> distributing the
>>> workload and giving the clerical user a better amd more responsive
>>> experience.
>>>
>>> As some examples, my recent testing of the sales order functionality
>>> shows
>>> that it takes ~ 200 msecs to complete the "userLogin" service or 120
>>> msecs
>>> to complete "calculateProductPrice" (these numbers are from the ofbiz
log
>>> file on a fairly fast machine with lots of debug output).  If this is
all
>>> done on the main ofbiz servers about 5 of the former and 10 of the
>>> later can
>>> be done simultaneously to maintain a reasonable lag time.  If the load
is
>>> spread out among say 8 desktops and 2 browser accesses, everyone has a
>>> really good experience.
>>>
>>> The only drawback to this all is that if the server configuration
>>> changes,
>>> the desktops must be patched as well.  In practice, that is not a big
>>> issue.
>>>
>>> So, it makes great sense to me to write desktop applications for common
>>> backoffice functions.
>>>
>>> I am currently working on a suite of such applications, hence my
>>> interest in
>>> BJs SWT based CRM.
>>>
>>> Skip
>>>
>>> -----Original Message-----
>>> From: David E Jones [mailto:jonesde@hotwaxmedia.com]
>>> Sent: Wednesday, October 03, 2007 11:12 AM
>>> To: user@ofbiz.apache.org
>>> Subject: Re: CRM - Customer Relationship Management facilities in OFBiz
>>>
>>>
>>>
>>> I'm not sure where this thread is leading or how it's related to
>>> OFBiz...
>>>
>>> In any case, there is CRM functionality in OFBiz. The first step
>>> would be defining in a little more detail what you mean by "CRM"
>>> since that means very different things in different companies. OFBiz
>>> does offer a single view into customer interactions including web
>>> site visits, phone/email/in-person/etc communications, requests,
>>> quotes, orders, shipments, invoices, payments, balance accounts,
>>> projects, calendar events, and many other things. You can also
>>> classify parties for marketing and sales, and do things like
>>> marketing campaigns including reference codes via email, snail mail,
>>> whatever.
>>>
>>> If you're looking for simple desktop contact management something
>>> like ACT or even salesforce.com would be better. If you're looking
>>> for enterprise CRM (especially a business or industry specific
>>> incarnation of such) then OFBiz a great basis for the effort.
>>>
>>> -David
>>>
>>>
>>> On Oct 3, 2007, at 11:07 AM, skip@theDevers wrote:
>>>
>>>> I'd like to see the SWT code as it is.  To heck with translating it
>>>> to use
>>>> web based widgets.
>>>>
>>>> I gotta set up a web site soon to hold code like this.
>>>>
>>>> Skip
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: BJ Freeman [mailto:bjfree@free-man.net]
>>>> Sent: Wednesday, October 03, 2007 3:06 AM
>>>> To: user@ofbiz.apache.org
>>>> Subject: Re: CRM - Customer Relationship Management facilities in
>>>> OFBiz
>>>>
>>>>
>>>> basically yes.
>>>> the tool i used added some classes to better manage things.
>>>> http://www.elance.com/p/?
>>>> q=eolproviderprofile&view_person=BJFreeman&catid=10
>>>> 182#tab=1
>>>> click on Java CRM
>>>>
>>>> skip@theDevers sent the following on 10/2/2007 8:55 PM:
>>>>> BJ
>>>>>
>>>>> SWT as in Eclipse SWT?
>>>>>
>>>>> Skip
>>>>>
>>>>> -----Original Message-----
>>>>> From: BJ Freeman [mailto:bjfree@free-man.net]
>>>>> Sent: Tuesday, October 02, 2007 8:26 PM
>>>>> To: user@ofbiz.apache.org
>>>>> Subject: Re: CRM - Customer Relationship Management facilities in
>>>>> OFBiz
>>>>>
>>>>>
>>>>> there at least two efforts going that i know of.
>>>>> the data model pretty much has all that you need.
>>>>> Si's implementation does not totally integrate with the current data
>>>>> storage. it is built on ofbiz but is supported under opentaps.
>>>>> Mine is something I am bringing over from Java SWT and SQL db.
>>>>> Once I figure out how to show the UI I want in widgets I will release
>>>>> it. Currently for my clients I use a java sWT that connects to ofbiz.
>>>>> It is built entirely within the current ofbiz datamodel.
>>>>> as soon as I get some irons of the fire will focus on it more
>>>>>
>>>>>
>>>>>
>>>>> Philip Laing sent the following on 10/2/2007 7:36 PM:
>>>>>> Thanks for your input relating my previous questions, I am
>>>>>> interested in
>>>>>> implementing some sort of Helpdesk/CRM system and I am interested
>>>>>> in what
>>>>>> facilities OFBiz already has
>>>>>>
>>>>>> Thanks
>>>>>> Phil
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>
>
>

Re: CRM - Customer Relationship Management facilities in OFBiz

Posted by Jonathon -- Improov <jo...@improov.com>.

Hey Skip,

Nice discussion. :)

 > 1.  Backoffice personell are expensive.

I was thinking more in terms of IT department savings. The "create/maintain/deploy" human 
activities can be quite a bit more expensive (IT consultants) than backoffice personnel, I would 
think. Is that the case where you are?

Still, saving manpower is always good. AJAX (and Web 2.0) technology came in to correct the 
pendulum swing, the swing from saving backoffice manpower (or end-users) to saving IT manpower. 
Yes, usability and end-user experience did suffer when the IT folks tried to save on the 
"create/maintain/deploy" side of things.

 > It takes 20 seconds less on simple orders (Finalize with defaults) and 45
 > seconds less with complicated ones using the Java app.

I had similar savings with AJAX. It's not so bad, really. After all, AJAX is done with javascript, 
and javascript is done with...? C/C++ or something similarly tight. The parser and runtime is in 
the browser itself! Now, where does Java stand in comparison? :)

I would imagine that your Java GUI app does trim and quick server calls (for quick 
synchronization) to the server. That's what AJAX does too.

 > I know I can achieve the same effect with ajax, but if I have to write these
 > apps from scratch anyway, why not take advantage of the extra horsepower and
 > compiled Java?

Because AJAX is still part of "server codes" (served up by server), so you can manage them 
centrally. Java client codes (GUI mostly?) is separated from server codes (separately installed on 
client). AJAX is coded as part of HTML pages served up by "server codes".

While a full Java app is fast enough for trigger-happy trigger-efficient backoffice personnel, it 
might be too expensive a swing in the pendulum. Yes, end-users did suffer when we swung from 
user-friendliness to IT savings. But should we now swing so vehemently back to user-friendliness 
(with Java client app), and move so far away from IT savings?

 > With Ofbiz code doing the grunt work, I can spend my time making the GUI
 > fast, easy, and smart.

Actually, that business model does work. GUI is everything to customers or end-users. Some 
customers will pay a lot just to have GUIs they like. However, most customers I know are 
cost-conscious, and won't want to pay for a Porsche paint job if they can get a cheaper and still 
effective GUI that works.

If your customer is willing to pay lots for future maintenance of Java GUI app, browser GUI 
modules (OFBiz widgets and such), and OFBiz backend modules, then sure, have fun doing all that 
maintenance.

Eg scenario: "Did you change the UI like I wanted?"... "Yes, I did"... "I see it only in the 
browser GUI modules"... "I'll do it in the Java GUI module too, sorry I forgot"... "Make sure you 
do the change exactly, I want the change to be precisely uniform and consistent".

 > 2.  "Also, the move forward is to "dumb down" the client terminals (cheap to
 > deploy, scalable)."... Witness the move to Ajax backed Javascript as an
 > example.

"Dumbing down" client terminals means we don't have to "teach" (install) those terminals too much. 
The point is to be able to acquire any computer (new or old), and still be able to run the app and 
hit the server, without having to "teach" or install much to those terminals.

AJAX is part of the browser. Browser adoption rates are driven by browser competition, not by our 
own Java GUI development team. With browser adoption moving along healthily, we can do away with 
our Java GUI development team (reassign).

 > It takes almost no time to code a GUI with Netbeans.

In software development, the biggest headaches isn't about getting something coded. It's about 
collaboration between IT teams, collaboration between software components (in your case, server 
and client components). And the need for such collaboration is so strong, version control 
mechanisms were born, and honed by now.

Take this DocBook example (since there was a recent mention of DocBooks somewhere). DocBook is 
plain text format, and can be automatically converted into OpenDocument format (MS Word equivalent 
in OpenOffice). OpenDocument format is binary. Suppose I write a huge book using OpenDocument 
format, and I make some changes. I would have to send a new complete binary of the whole book to 
my publisher. But with DocBook's plain text format, plus version control, I only need to send a 
small diff to update (collaborate with) my publisher.

More than 10 years back, I remember a time when we used MS Word documents for functional specs. 
Lots of protocols then for change management, under project management. For every change in the 
specs documents, a "changelog" section needs to be carefully and painstakingly updated. In 
reality, there were many "carefully and painstakingly" crafted errors in those "changelog" 
sections. We're just humans. There was simply no way to do a "diff" for MS Word docs.

 > No such tools currently exist (that I know of) for Ajax backed apps.

It may take some time for AJAX frameworks to compete and crystallize some standards. Or has that 
already happened? Still, it isn't difficult to do AJAX. It's almost standard by now.

 > 4.  "In production, servers aren't hit all the time. There are peak periods,
 > and there are lull periods."  If the brains are on the user's desktop, there
 > are no lull or peaks at any time (and no associated aggravation).  Their
 > work is never interrupted or slowed (assuming the database server is not
 > overloaded.)

Even if you put the Java GUI app on the client terminals, you'll still need to handle peak periods 
on the server codes. If you're already doing clustering and load-balancing on the server side, you 
might as well do it there only, and gain the benefit of "easier control" (only a few servers, 
platforms and setups you can control).

If you're thinking of executing business logic codes on the client terminals, you face the 
additional risk of such codes running differently on different terminals. We never know. Sun SDK 
could run a tad different on some setups. There'd be so many different setups or platforms to 
cater for, the cost of maintenance could increase exponentially.

To fix that problem, you could mandate a uniform setup for all client terminals. So, if the top 
boss wants a newfangled 128-bit computer, and still wants to run your Java GUI app, would you be 
able to tell him "Sir, you gotta get with the program because Sun SDK won't run with 128-bit"? :)

Using only browsers as the client app, the responsibility to "cater for various platforms" falls 
on the browser developers instead.

 > 5.  "Those folks writing the "offloading algorithms" won't know how fast/slow
 > my computer is."  Gads Jonathon, I couldnt agree more.  I get aggravated
 > daily waiting for Javascript intensive web pages to download.  However, I am
 > not running javascript, but blazingly fast compiled Java.  If the user's
 > machine doesnt have the guts, I wouldn't install Ofbiz on it.  They can use a
 > browser to access the same funcionality.

Then you'd have double the maintenance responsibility.

You not only have to maintain the server codes that servers up GUI via browser, you also have to 
maintain the Java GUI app.

Finally, you may argue that javascript is just too difficult to handle (I hate it too). Browsers 
might deal with javascript so differently (or even wrongly at times). You could consider mandating 
that every dumb terminal installs a new browser (the winner then). The best browser out there will 
be a cinch to install. There's ready support for the browser. Many great browsers are now free, 
even opensource. Will your Java GUI app be able to compete with the polish that goes into browser 
development and support?

Jonathon

skip@theDevers wrote:
> Johathon
> 
> Hmmm, you've almost got me convinced to give this up.  So convinced in fact
> that I am gonna forward this email on to my current customer and get his
> reaction.  It's well thought out and you obviously spent a great deal of
> time thinking about it and I thank you for it lavishly.
> 
> Still, I have these arguments in favor to offer:
> 
> 1.  Backoffice personell are expensive.  Even saving them 10 minutes (that's
> 10 seconds a transaction or less) a day translates to $3000 a year even for
> the lower paid ones, and this is per-person.  I have timed myself using the
> Ofbiz "Order Entry" screen to enter a two item sale and the desktop Java
> based order entry application I am currently finishing.  The results?  It
> takes 20 seconds less on simple orders (Finalize with defaults) and 45
> seconds less with complicated ones using the Java app. And, all my code is
> using the stock Ofbiz services to do the real work so it's fairly simple to
> write.  The difference in time is because I can change the control having
> the input focus intelligently and I don't have to wait for brower repaints
> between atomic operations.  A fast operator can go as fast as they can type.
> I know I can achieve the same effect with ajax, but if I have to write these
> apps from scratch anyway, why not take advantage of the extra horsepower and
> compiled Java?  By the way, the nearly finished Java app is surprisingly
> small.  With Ofbiz code doing the grunt work, I can spend my time making the
> GUI fast, easy, and smart.
> 
> 2.  "Also, the move forward is to "dumb down" the client terminals (cheap to
> deploy, scalable)."  I would partially disagree with this although it is
> repeated a lot.  This was certainly true a couple of years ago, but lately,
> we are heading back in the other direction.  Witness the move to Ajax backed
> Javascript as an example. It takes almost no time to code a GUI with
> Netbeans.  No such tools currently exist (that I know of) for Ajax backed
> apps.  Also. go look at the sales stats for Dell and HP and you will see
> that the  majority of their sales are to business and it shows no signs of
> slowing (although it is not increasing as fast as it was a few years ago).
> 
> 3.  "Even if the client terminals just happen to be blazing fast enough for
> graphics-intensive work...".  Graphics-intensive capability is more a factor
> of the video card than the CPU.  EVERY desktop I see with an A/R or A/P
> person in the chair is capable of running Ofbiz, Word and Excel at the same
> time.  On my test box, I have Ofbiz running with Netbeans, Visual Studio,
> Gaim, and Outlook and it's no smoker and joker.
> 
> 4.  "In production, servers aren't hit all the time. There are peak periods,
> and there are lull periods."  If the brains are on the user's desktop, there
> are no lull or peaks at any time (and no associated aggravation).  Their
> work is never interrupted or slowed (assuming the database server is not
> overloaded.)
> 
> 
> 5.  "Those folks writing the "offloading algorithms" won't know how
> fast/slow my computer is."  Gads Jonathon, I couldnt agree more.  I get
> aggravated daily waiting for Javascript intensive web pages to download.
> However, I am not running javascript, but blazingly fast compiled Java.  If
> the user's machine doesnt have the guts, I wouldn't install Ofbiz on it.
> They can use a browser to access the same funcionality.
> 
> 
> Hmmm, now I've almost convinced myself to carry on. :)
> 
> Cheers
> 
> Skip
> 
> 
> -----Original Message-----
> From: Jonathon -- Improov [mailto:jonw@improov.com]
> Sent: Wednesday, October 03, 2007 7:43 PM
> To: user@ofbiz.apache.org
> Subject: Re: CRM - Customer Relationship Management facilities in OFBiz
> 
> 
>  > You might be surprised by how expensive such a solution would be to
>  > create/maintain/deploy and how little it will help on server resources.
> 
> I have many clients wanting to move away from that distributed (client
> codes) model to the
> centralized (server codes) model. Yes, it is proving to be expensive. Kinda
> "tried and tested" to
> be expensive, actually.
> 
> "Create/maintain/deploy" are all human activities. Will be inordinately
> expensive to create
> artificial intelligence to do all that. In general (with our current
> state-of-the-art of AI), it
> is cheaper to simply upgrade the server hardware. Yes, computer hardware
> speed improvement may be
> slowing down now (used to be doubling every 1.5 years?). But there will
> surely be something new
> coming up (quantum computers, multi-state logic units, etc), unless we're
> suddenly hit by an
> epidemic that halves human intelligence every 1.5 years. (Or I infect all
> you guys with my stupidity).
> 
> Also, the move forward is to "dumb down" the client terminals (cheap to
> deploy, scalable). Even if
> the client terminals just happen to be blazing fast enough for
> graphics-intensive work, perhaps
> those terminals' users' job scope is to do graphics-intensive work on a
> regular basis? Putting a
> part of OFBiz into those machines will compromise the efficiency of their
> graphics-intensive work.
> 
> As for "You might be surprised", I'm ALWAYS surprised when it comes to doing
> optimization work!
> Optimization needs are very hard to calculate and predict by hand. Rather
> than spend weeks using
> complex maths and theories to predict (presume, rather) bottle-necks, it's
> easier to spend a
> couple of hours to do an actual measurement of computation speeds.
> 
>  > You might also be surprised by how capable servers are of handling
>  > concurrent load, how different performance tends to be in a development
>  > versus production environment, and for certain things how easy it is to
>  > tune them once the slowest stuff has been identified.
> 
> In production, servers aren't hit all the time. There are peak periods, and
> there are lull
> periods. To handle such cases, clustering and load-balancing is the usual
> practice. The diff
> between clustering servers and using smart client terminals, both being
> distributed models, is
> this... it's easier to monitor and tune a few servers than to do so for
> hundreds of client terminals.
> 
> Also, consider how irritating javascript is getting to be, those that try to
> offload huge amounts
> of servers' workloads into our personal computers. Those folks writing the
> "offloading algorithms"
> won't know how fast/slow my computer is, and could render my computer
> completely useless by
> overloading it.
> 
> But before going into clustering, it is often adequate to spot the
> bottle-necks in a single
> server, and optimize just those areas. That'll help the OFBiz framework and
> help the OFBiz
> community too.
> 
> For all the optimization smarts we have, I must say that I had
> over-optimized before in my career.
> In business, over-optimizing a system isn't "passing with flying colors",
> but actually translates
> into a loss. While it is great to "push the envelope", it'll help in thesis
> writing more than in
> business. Study the bottle-necks in production settings, and fix just those.
> 
> Still, please feel free to over-optimize the OFBiz framework! That's a
> different scenario. Huge ROI.
> 
> Jonathon
> 
> David E Jones wrote:
>> You might be surprised by how expensive such a solution would be to
>> create/maintain/deploy and how little it will help on server resources.
>> You might also be surprised by how capable servers are of handling
>> concurrent load, how different performance tends to be in a development
>> versus production environment, and for certain things how easy it is to
>> tune them once the slowest stuff has been identified.
>>
>> -David
>>
>>
>> On Oct 3, 2007, at 1:05 PM, skip@theDevers wrote:
>>
>>> David
>>>
>>> This issue here to me asset utilization.  In a typical mid-sized company,
>>> there are dozens or hundreds of desktop computers that their user use
>>> to do
>>> their daily work.  If the user is using a browser to access logic on
>>> one of
>>> Ofbiz servers, the desktop is under-utilized.  By tying in a desktop
>>> application to Ofbiz (i.e. running an entity engine on the desktop
>>> tied to
>>> the same database as the main ofbiz servers and running xml setups
>>> identical
>>> to the servers), that workload is performed on the users desktop and
>>> not on
>>> the main ofbiz servers thereby freeing the server for functionality that
>>> REQUIRES browser based access.
>>>
>>> This does not in any way supplant Ofbiz, it enhances it by
>>> distributing the
>>> workload and giving the clerical user a better amd more responsive
>>> experience.
>>>
>>> As some examples, my recent testing of the sales order functionality
>>> shows
>>> that it takes ~ 200 msecs to complete the "userLogin" service or 120
>>> msecs
>>> to complete "calculateProductPrice" (these numbers are from the ofbiz log
>>> file on a fairly fast machine with lots of debug output).  If this is all
>>> done on the main ofbiz servers about 5 of the former and 10 of the
>>> later can
>>> be done simultaneously to maintain a reasonable lag time.  If the load is
>>> spread out among say 8 desktops and 2 browser accesses, everyone has a
>>> really good experience.
>>>
>>> The only drawback to this all is that if the server configuration
>>> changes,
>>> the desktops must be patched as well.  In practice, that is not a big
>>> issue.
>>>
>>> So, it makes great sense to me to write desktop applications for common
>>> backoffice functions.
>>>
>>> I am currently working on a suite of such applications, hence my
>>> interest in
>>> BJs SWT based CRM.
>>>
>>> Skip
>>>
>>> -----Original Message-----
>>> From: David E Jones [mailto:jonesde@hotwaxmedia.com]
>>> Sent: Wednesday, October 03, 2007 11:12 AM
>>> To: user@ofbiz.apache.org
>>> Subject: Re: CRM - Customer Relationship Management facilities in OFBiz
>>>
>>>
>>>
>>> I'm not sure where this thread is leading or how it's related to
>>> OFBiz...
>>>
>>> In any case, there is CRM functionality in OFBiz. The first step
>>> would be defining in a little more detail what you mean by "CRM"
>>> since that means very different things in different companies. OFBiz
>>> does offer a single view into customer interactions including web
>>> site visits, phone/email/in-person/etc communications, requests,
>>> quotes, orders, shipments, invoices, payments, balance accounts,
>>> projects, calendar events, and many other things. You can also
>>> classify parties for marketing and sales, and do things like
>>> marketing campaigns including reference codes via email, snail mail,
>>> whatever.
>>>
>>> If you're looking for simple desktop contact management something
>>> like ACT or even salesforce.com would be better. If you're looking
>>> for enterprise CRM (especially a business or industry specific
>>> incarnation of such) then OFBiz a great basis for the effort.
>>>
>>> -David
>>>
>>>
>>> On Oct 3, 2007, at 11:07 AM, skip@theDevers wrote:
>>>
>>>> I'd like to see the SWT code as it is.  To heck with translating it
>>>> to use
>>>> web based widgets.
>>>>
>>>> I gotta set up a web site soon to hold code like this.
>>>>
>>>> Skip
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: BJ Freeman [mailto:bjfree@free-man.net]
>>>> Sent: Wednesday, October 03, 2007 3:06 AM
>>>> To: user@ofbiz.apache.org
>>>> Subject: Re: CRM - Customer Relationship Management facilities in
>>>> OFBiz
>>>>
>>>>
>>>> basically yes.
>>>> the tool i used added some classes to better manage things.
>>>> http://www.elance.com/p/?
>>>> q=eolproviderprofile&view_person=BJFreeman&catid=10
>>>> 182#tab=1
>>>> click on Java CRM
>>>>
>>>> skip@theDevers sent the following on 10/2/2007 8:55 PM:
>>>>> BJ
>>>>>
>>>>> SWT as in Eclipse SWT?
>>>>>
>>>>> Skip
>>>>>
>>>>> -----Original Message-----
>>>>> From: BJ Freeman [mailto:bjfree@free-man.net]
>>>>> Sent: Tuesday, October 02, 2007 8:26 PM
>>>>> To: user@ofbiz.apache.org
>>>>> Subject: Re: CRM - Customer Relationship Management facilities in
>>>>> OFBiz
>>>>>
>>>>>
>>>>> there at least two efforts going that i know of.
>>>>> the data model pretty much has all that you need.
>>>>> Si's implementation does not totally integrate with the current data
>>>>> storage. it is built on ofbiz but is supported under opentaps.
>>>>> Mine is something I am bringing over from Java SWT and SQL db.
>>>>> Once I figure out how to show the UI I want in widgets I will release
>>>>> it. Currently for my clients I use a java sWT that connects to ofbiz.
>>>>> It is built entirely within the current ofbiz datamodel.
>>>>> as soon as I get some irons of the fire will focus on it more
>>>>>
>>>>>
>>>>>
>>>>> Philip Laing sent the following on 10/2/2007 7:36 PM:
>>>>>> Thanks for your input relating my previous questions, I am
>>>>>> interested in
>>>>>> implementing some sort of Helpdesk/CRM system and I am interested
>>>>>> in what
>>>>>> facilities OFBiz already has
>>>>>>
>>>>>> Thanks
>>>>>> Phil
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>
> 
> 
>

RE: CRM - Customer Relationship Management facilities in OFBiz

Posted by "skip@theDevers" <sk...@thedevers.org>.

Johathon

Hmmm, you've almost got me convinced to give this up.  So convinced in fact
that I am gonna forward this email on to my current customer and get his
reaction.  It's well thought out and you obviously spent a great deal of
time thinking about it and I thank you for it lavishly.

Still, I have these arguments in favor to offer:

1.  Backoffice personell are expensive.  Even saving them 10 minutes (that's
10 seconds a transaction or less) a day translates to $3000 a year even for
the lower paid ones, and this is per-person.  I have timed myself using the
Ofbiz "Order Entry" screen to enter a two item sale and the desktop Java
based order entry application I am currently finishing.  The results?  It
takes 20 seconds less on simple orders (Finalize with defaults) and 45
seconds less with complicated ones using the Java app. And, all my code is
using the stock Ofbiz services to do the real work so it's fairly simple to
write.  The difference in time is because I can change the control having
the input focus intelligently and I don't have to wait for brower repaints
between atomic operations.  A fast operator can go as fast as they can type.
I know I can achieve the same effect with ajax, but if I have to write these
apps from scratch anyway, why not take advantage of the extra horsepower and
compiled Java?  By the way, the nearly finished Java app is surprisingly
small.  With Ofbiz code doing the grunt work, I can spend my time making the
GUI fast, easy, and smart.

2.  "Also, the move forward is to "dumb down" the client terminals (cheap to
deploy, scalable)."  I would partially disagree with this although it is
repeated a lot.  This was certainly true a couple of years ago, but lately,
we are heading back in the other direction.  Witness the move to Ajax backed
Javascript as an example. It takes almost no time to code a GUI with
Netbeans.  No such tools currently exist (that I know of) for Ajax backed
apps.  Also. go look at the sales stats for Dell and HP and you will see
that the  majority of their sales are to business and it shows no signs of
slowing (although it is not increasing as fast as it was a few years ago).

3.  "Even if the client terminals just happen to be blazing fast enough for
graphics-intensive work...".  Graphics-intensive capability is more a factor
of the video card than the CPU.  EVERY desktop I see with an A/R or A/P
person in the chair is capable of running Ofbiz, Word and Excel at the same
time.  On my test box, I have Ofbiz running with Netbeans, Visual Studio,
Gaim, and Outlook and it's no smoker and joker.

4.  "In production, servers aren't hit all the time. There are peak periods,
and there are lull periods."  If the brains are on the user's desktop, there
are no lull or peaks at any time (and no associated aggravation).  Their
work is never interrupted or slowed (assuming the database server is not
overloaded.)

5.  "Those folks writing the "offloading algorithms" won't know how
fast/slow my computer is."  Gads Jonathon, I couldnt agree more.  I get
aggravated daily waiting for Javascript intensive web pages to download.
However, I am not running javascript, but blazingly fast compiled Java.  If
the user's machine doesnt have the guts, I wouldn't install Ofbiz on it.
They can use a browser to access the same funcionality.

Hmmm, now I've almost convinced myself to carry on. :)

Cheers

Skip

-----Original Message-----
From: Jonathon -- Improov [mailto:jonw@improov.com]
Sent: Wednesday, October 03, 2007 7:43 PM
To: user@ofbiz.apache.org
Subject: Re: CRM - Customer Relationship Management facilities in OFBiz

 > You might be surprised by how expensive such a solution would be to
 > create/maintain/deploy and how little it will help on server resources.

I have many clients wanting to move away from that distributed (client
codes) model to the
centralized (server codes) model. Yes, it is proving to be expensive. Kinda
"tried and tested" to
be expensive, actually.

"Create/maintain/deploy" are all human activities. Will be inordinately
expensive to create
artificial intelligence to do all that. In general (with our current
state-of-the-art of AI), it
is cheaper to simply upgrade the server hardware. Yes, computer hardware
speed improvement may be
slowing down now (used to be doubling every 1.5 years?). But there will
surely be something new
coming up (quantum computers, multi-state logic units, etc), unless we're
suddenly hit by an
epidemic that halves human intelligence every 1.5 years. (Or I infect all
you guys with my stupidity).

Also, the move forward is to "dumb down" the client terminals (cheap to
deploy, scalable). Even if
the client terminals just happen to be blazing fast enough for
graphics-intensive work, perhaps
those terminals' users' job scope is to do graphics-intensive work on a
regular basis? Putting a
part of OFBiz into those machines will compromise the efficiency of their
graphics-intensive work.

As for "You might be surprised", I'm ALWAYS surprised when it comes to doing
optimization work!
Optimization needs are very hard to calculate and predict by hand. Rather
than spend weeks using
complex maths and theories to predict (presume, rather) bottle-necks, it's
easier to spend a
couple of hours to do an actual measurement of computation speeds.

 > You might also be surprised by how capable servers are of handling
 > concurrent load, how different performance tends to be in a development
 > versus production environment, and for certain things how easy it is to
 > tune them once the slowest stuff has been identified.

In production, servers aren't hit all the time. There are peak periods, and
there are lull
periods. To handle such cases, clustering and load-balancing is the usual
practice. The diff
between clustering servers and using smart client terminals, both being
distributed models, is
this... it's easier to monitor and tune a few servers than to do so for
hundreds of client terminals.

Also, consider how irritating javascript is getting to be, those that try to
offload huge amounts
of servers' workloads into our personal computers. Those folks writing the
"offloading algorithms"
won't know how fast/slow my computer is, and could render my computer
completely useless by
overloading it.

But before going into clustering, it is often adequate to spot the
bottle-necks in a single
server, and optimize just those areas. That'll help the OFBiz framework and
help the OFBiz
community too.

For all the optimization smarts we have, I must say that I had
over-optimized before in my career.
In business, over-optimizing a system isn't "passing with flying colors",
but actually translates
into a loss. While it is great to "push the envelope", it'll help in thesis
writing more than in
business. Study the bottle-necks in production settings, and fix just those.

Still, please feel free to over-optimize the OFBiz framework! That's a
different scenario. Huge ROI.

Jonathon

David E Jones wrote:
>
> You might be surprised by how expensive such a solution would be to
> create/maintain/deploy and how little it will help on server resources.
> You might also be surprised by how capable servers are of handling
> concurrent load, how different performance tends to be in a development
> versus production environment, and for certain things how easy it is to
> tune them once the slowest stuff has been identified.
>
> -David
>
>
> On Oct 3, 2007, at 1:05 PM, skip@theDevers wrote:
>
>> David
>>
>> This issue here to me asset utilization.  In a typical mid-sized company,
>> there are dozens or hundreds of desktop computers that their user use
>> to do
>> their daily work.  If the user is using a browser to access logic on
>> one of
>> Ofbiz servers, the desktop is under-utilized.  By tying in a desktop
>> application to Ofbiz (i.e. running an entity engine on the desktop
>> tied to
>> the same database as the main ofbiz servers and running xml setups
>> identical
>> to the servers), that workload is performed on the users desktop and
>> not on
>> the main ofbiz servers thereby freeing the server for functionality that
>> REQUIRES browser based access.
>>
>> This does not in any way supplant Ofbiz, it enhances it by
>> distributing the
>> workload and giving the clerical user a better amd more responsive
>> experience.
>>
>> As some examples, my recent testing of the sales order functionality
>> shows
>> that it takes ~ 200 msecs to complete the "userLogin" service or 120
>> msecs
>> to complete "calculateProductPrice" (these numbers are from the ofbiz log
>> file on a fairly fast machine with lots of debug output).  If this is all
>> done on the main ofbiz servers about 5 of the former and 10 of the
>> later can
>> be done simultaneously to maintain a reasonable lag time.  If the load is
>> spread out among say 8 desktops and 2 browser accesses, everyone has a
>> really good experience.
>>
>> The only drawback to this all is that if the server configuration
>> changes,
>> the desktops must be patched as well.  In practice, that is not a big
>> issue.
>>
>> So, it makes great sense to me to write desktop applications for common
>> backoffice functions.
>>
>> I am currently working on a suite of such applications, hence my
>> interest in
>> BJs SWT based CRM.
>>
>> Skip
>>
>> -----Original Message-----
>> From: David E Jones [mailto:jonesde@hotwaxmedia.com]
>> Sent: Wednesday, October 03, 2007 11:12 AM
>> To: user@ofbiz.apache.org
>> Subject: Re: CRM - Customer Relationship Management facilities in OFBiz
>>
>>
>>
>> I'm not sure where this thread is leading or how it's related to
>> OFBiz...
>>
>> In any case, there is CRM functionality in OFBiz. The first step
>> would be defining in a little more detail what you mean by "CRM"
>> since that means very different things in different companies. OFBiz
>> does offer a single view into customer interactions including web
>> site visits, phone/email/in-person/etc communications, requests,
>> quotes, orders, shipments, invoices, payments, balance accounts,
>> projects, calendar events, and many other things. You can also
>> classify parties for marketing and sales, and do things like
>> marketing campaigns including reference codes via email, snail mail,
>> whatever.
>>
>> If you're looking for simple desktop contact management something
>> like ACT or even salesforce.com would be better. If you're looking
>> for enterprise CRM (especially a business or industry specific
>> incarnation of such) then OFBiz a great basis for the effort.
>>
>> -David
>>
>>
>> On Oct 3, 2007, at 11:07 AM, skip@theDevers wrote:
>>
>>> I'd like to see the SWT code as it is.  To heck with translating it
>>> to use
>>> web based widgets.
>>>
>>> I gotta set up a web site soon to hold code like this.
>>>
>>> Skip
>>>
>>>
>>> -----Original Message-----
>>> From: BJ Freeman [mailto:bjfree@free-man.net]
>>> Sent: Wednesday, October 03, 2007 3:06 AM
>>> To: user@ofbiz.apache.org
>>> Subject: Re: CRM - Customer Relationship Management facilities in
>>> OFBiz
>>>
>>>
>>> basically yes.
>>> the tool i used added some classes to better manage things.
>>> http://www.elance.com/p/?
>>> q=eolproviderprofile&view_person=BJFreeman&catid=10
>>> 182#tab=1
>>> click on Java CRM
>>>
>>> skip@theDevers sent the following on 10/2/2007 8:55 PM:
>>>> BJ
>>>>
>>>> SWT as in Eclipse SWT?
>>>>
>>>> Skip
>>>>
>>>> -----Original Message-----
>>>> From: BJ Freeman [mailto:bjfree@free-man.net]
>>>> Sent: Tuesday, October 02, 2007 8:26 PM
>>>> To: user@ofbiz.apache.org
>>>> Subject: Re: CRM - Customer Relationship Management facilities in
>>>> OFBiz
>>>>
>>>>
>>>> there at least two efforts going that i know of.
>>>> the data model pretty much has all that you need.
>>>> Si's implementation does not totally integrate with the current data
>>>> storage. it is built on ofbiz but is supported under opentaps.
>>>> Mine is something I am bringing over from Java SWT and SQL db.
>>>> Once I figure out how to show the UI I want in widgets I will release
>>>> it. Currently for my clients I use a java sWT that connects to ofbiz.
>>>> It is built entirely within the current ofbiz datamodel.
>>>> as soon as I get some irons of the fire will focus on it more
>>>>
>>>>
>>>>
>>>> Philip Laing sent the following on 10/2/2007 7:36 PM:
>>>>> Thanks for your input relating my previous questions, I am
>>>>> interested in
>>>>> implementing some sort of Helpdesk/CRM system and I am interested
>>>>> in what
>>>>> facilities OFBiz already has
>>>>>
>>>>> Thanks
>>>>> Phil
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>

Re: CRM - Customer Relationship Management facilities in OFBiz

Posted by Jonathon -- Improov <jo...@improov.com>.

 > You might be surprised by how expensive such a solution would be to
 > create/maintain/deploy and how little it will help on server resources.

I have many clients wanting to move away from that distributed (client codes) model to the 
centralized (server codes) model. Yes, it is proving to be expensive. Kinda "tried and tested" to 
be expensive, actually.

"Create/maintain/deploy" are all human activities. Will be inordinately expensive to create 
artificial intelligence to do all that. In general (with our current state-of-the-art of AI), it 
is cheaper to simply upgrade the server hardware. Yes, computer hardware speed improvement may be 
slowing down now (used to be doubling every 1.5 years?). But there will surely be something new 
coming up (quantum computers, multi-state logic units, etc), unless we're suddenly hit by an 
epidemic that halves human intelligence every 1.5 years. (Or I infect all you guys with my stupidity).

Also, the move forward is to "dumb down" the client terminals (cheap to deploy, scalable). Even if 
the client terminals just happen to be blazing fast enough for graphics-intensive work, perhaps 
those terminals' users' job scope is to do graphics-intensive work on a regular basis? Putting a 
part of OFBiz into those machines will compromise the efficiency of their graphics-intensive work.

As for "You might be surprised", I'm ALWAYS surprised when it comes to doing optimization work! 
Optimization needs are very hard to calculate and predict by hand. Rather than spend weeks using 
complex maths and theories to predict (presume, rather) bottle-necks, it's easier to spend a 
couple of hours to do an actual measurement of computation speeds.

 > You might also be surprised by how capable servers are of handling
 > concurrent load, how different performance tends to be in a development
 > versus production environment, and for certain things how easy it is to
 > tune them once the slowest stuff has been identified.

In production, servers aren't hit all the time. There are peak periods, and there are lull 
periods. To handle such cases, clustering and load-balancing is the usual practice. The diff 
between clustering servers and using smart client terminals, both being distributed models, is 
this... it's easier to monitor and tune a few servers than to do so for hundreds of client terminals.

Also, consider how irritating javascript is getting to be, those that try to offload huge amounts 
of servers' workloads into our personal computers. Those folks writing the "offloading algorithms" 
won't know how fast/slow my computer is, and could render my computer completely useless by 
overloading it.

But before going into clustering, it is often adequate to spot the bottle-necks in a single 
server, and optimize just those areas. That'll help the OFBiz framework and help the OFBiz 
community too.

For all the optimization smarts we have, I must say that I had over-optimized before in my career. 
In business, over-optimizing a system isn't "passing with flying colors", but actually translates 
into a loss. While it is great to "push the envelope", it'll help in thesis writing more than in 
business. Study the bottle-necks in production settings, and fix just those.

Still, please feel free to over-optimize the OFBiz framework! That's a different scenario. Huge ROI.

Jonathon

David E Jones wrote:
> 
> You might be surprised by how expensive such a solution would be to 
> create/maintain/deploy and how little it will help on server resources. 
> You might also be surprised by how capable servers are of handling 
> concurrent load, how different performance tends to be in a development 
> versus production environment, and for certain things how easy it is to 
> tune them once the slowest stuff has been identified.
> 
> -David
> 
> 
> On Oct 3, 2007, at 1:05 PM, skip@theDevers wrote:
> 
>> David
>>
>> This issue here to me asset utilization.  In a typical mid-sized company,
>> there are dozens or hundreds of desktop computers that their user use 
>> to do
>> their daily work.  If the user is using a browser to access logic on 
>> one of
>> Ofbiz servers, the desktop is under-utilized.  By tying in a desktop
>> application to Ofbiz (i.e. running an entity engine on the desktop 
>> tied to
>> the same database as the main ofbiz servers and running xml setups 
>> identical
>> to the servers), that workload is performed on the users desktop and 
>> not on
>> the main ofbiz servers thereby freeing the server for functionality that
>> REQUIRES browser based access.
>>
>> This does not in any way supplant Ofbiz, it enhances it by 
>> distributing the
>> workload and giving the clerical user a better amd more responsive
>> experience.
>>
>> As some examples, my recent testing of the sales order functionality 
>> shows
>> that it takes ~ 200 msecs to complete the "userLogin" service or 120 
>> msecs
>> to complete "calculateProductPrice" (these numbers are from the ofbiz log
>> file on a fairly fast machine with lots of debug output).  If this is all
>> done on the main ofbiz servers about 5 of the former and 10 of the 
>> later can
>> be done simultaneously to maintain a reasonable lag time.  If the load is
>> spread out among say 8 desktops and 2 browser accesses, everyone has a
>> really good experience.
>>
>> The only drawback to this all is that if the server configuration 
>> changes,
>> the desktops must be patched as well.  In practice, that is not a big 
>> issue.
>>
>> So, it makes great sense to me to write desktop applications for common
>> backoffice functions.
>>
>> I am currently working on a suite of such applications, hence my 
>> interest in
>> BJs SWT based CRM.
>>
>> Skip
>>
>> -----Original Message-----
>> From: David E Jones [mailto:jonesde@hotwaxmedia.com]
>> Sent: Wednesday, October 03, 2007 11:12 AM
>> To: user@ofbiz.apache.org
>> Subject: Re: CRM - Customer Relationship Management facilities in OFBiz
>>
>>
>>
>> I'm not sure where this thread is leading or how it's related to
>> OFBiz...
>>
>> In any case, there is CRM functionality in OFBiz. The first step
>> would be defining in a little more detail what you mean by "CRM"
>> since that means very different things in different companies. OFBiz
>> does offer a single view into customer interactions including web
>> site visits, phone/email/in-person/etc communications, requests,
>> quotes, orders, shipments, invoices, payments, balance accounts,
>> projects, calendar events, and many other things. You can also
>> classify parties for marketing and sales, and do things like
>> marketing campaigns including reference codes via email, snail mail,
>> whatever.
>>
>> If you're looking for simple desktop contact management something
>> like ACT or even salesforce.com would be better. If you're looking
>> for enterprise CRM (especially a business or industry specific
>> incarnation of such) then OFBiz a great basis for the effort.
>>
>> -David
>>
>>
>> On Oct 3, 2007, at 11:07 AM, skip@theDevers wrote:
>>
>>> I'd like to see the SWT code as it is.  To heck with translating it
>>> to use
>>> web based widgets.
>>>
>>> I gotta set up a web site soon to hold code like this.
>>>
>>> Skip
>>>
>>>
>>> -----Original Message-----
>>> From: BJ Freeman [mailto:bjfree@free-man.net]
>>> Sent: Wednesday, October 03, 2007 3:06 AM
>>> To: user@ofbiz.apache.org
>>> Subject: Re: CRM - Customer Relationship Management facilities in
>>> OFBiz
>>>
>>>
>>> basically yes.
>>> the tool i used added some classes to better manage things.
>>> http://www.elance.com/p/?
>>> q=eolproviderprofile&view_person=BJFreeman&catid=10
>>> 182#tab=1
>>> click on Java CRM
>>>
>>> skip@theDevers sent the following on 10/2/2007 8:55 PM:
>>>> BJ
>>>>
>>>> SWT as in Eclipse SWT?
>>>>
>>>> Skip
>>>>
>>>> -----Original Message-----
>>>> From: BJ Freeman [mailto:bjfree@free-man.net]
>>>> Sent: Tuesday, October 02, 2007 8:26 PM
>>>> To: user@ofbiz.apache.org
>>>> Subject: Re: CRM - Customer Relationship Management facilities in
>>>> OFBiz
>>>>
>>>>
>>>> there at least two efforts going that i know of.
>>>> the data model pretty much has all that you need.
>>>> Si's implementation does not totally integrate with the current data
>>>> storage. it is built on ofbiz but is supported under opentaps.
>>>> Mine is something I am bringing over from Java SWT and SQL db.
>>>> Once I figure out how to show the UI I want in widgets I will release
>>>> it. Currently for my clients I use a java sWT that connects to ofbiz.
>>>> It is built entirely within the current ofbiz datamodel.
>>>> as soon as I get some irons of the fire will focus on it more
>>>>
>>>>
>>>>
>>>> Philip Laing sent the following on 10/2/2007 7:36 PM:
>>>>> Thanks for your input relating my previous questions, I am
>>>>> interested in
>>>>> implementing some sort of Helpdesk/CRM system and I am interested
>>>>> in what
>>>>> facilities OFBiz already has
>>>>>
>>>>> Thanks
>>>>> Phil
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>

Re: CRM - Customer Relationship Management facilities in OFBiz

Posted by Adrian Crum <ad...@hlmksw.com>.

And don't forget to read up on the OFBiz performance optimization tips on the Wiki.


David E Jones wrote:

> 
> On a decent 2 processor server a fairly normal load is around 100-200  
> active threads.
> 
> BTW, I just re-read what I wrote and I noticed I said "you" a lot,  but 
> I didn't mean you personally, substituting "one" would be more of  what 
> I meant. The interesting thing about all of that is that most  people 
> are surprised by the results and what actually makes things  slow unless 
> they've been through a number of performance reviews and  optimization 
> efforts, and that for a specific type of application.
> 
> -David
> 
> 
> On Oct 3, 2007, at 3:16 PM, skip@theDevers wrote:
> 
>> David
>>
>> Thanks for the input.  As far as the "create/maintain/deploy" part,  I 
>> think
>> I have a handle on that and am comfortable with the issues involved.
>> However, I must bow to your experience on "surprised by how capable  
>> servers
>> are of  handling concurrent load" part as I have done no testing on  
>> this at
>> all and am therefore just making extrapolations based on single  user 
>> usage.
>>
>> Any insite that you have regarding the number of concurrent users  per 
>> server
>> box would be appreciated. I would hate to get too far down this  road 
>> I am on
>> only to discover that it was a waste of time.
>>
>> Skip
>>
>> -----Original Message-----
>> From: David E Jones [mailto:jonesde@hotwaxmedia.com]
>> Sent: Wednesday, October 03, 2007 1:09 PM
>> To: user@ofbiz.apache.org
>> Subject: Re: CRM - Customer Relationship Management facilities in  OFBiz
>>
>>
>>
>> You might be surprised by how expensive such a solution would be to
>> create/maintain/deploy and how little it will help on server
>> resources. You might also be surprised by how capable servers are of
>> handling concurrent load, how different performance tends to be in a
>> development versus production environment, and for certain things how
>> easy it is to tune them once the slowest stuff has been identified.
>>
>> -David
>>
>>
>> On Oct 3, 2007, at 1:05 PM, skip@theDevers wrote:
>>
>>> David
>>>
>>> This issue here to me asset utilization.  In a typical mid-sized
>>> company,
>>> there are dozens or hundreds of desktop computers that their user
>>> use to do
>>> their daily work.  If the user is using a browser to access logic
>>> on one of
>>> Ofbiz servers, the desktop is under-utilized.  By tying in a desktop
>>> application to Ofbiz (i.e. running an entity engine on the desktop
>>> tied to
>>> the same database as the main ofbiz servers and running xml setups
>>> identical
>>> to the servers), that workload is performed on the users desktop
>>> and not on
>>> the main ofbiz servers thereby freeing the server for functionality
>>> that
>>> REQUIRES browser based access.
>>>
>>> This does not in any way supplant Ofbiz, it enhances it by
>>> distributing the
>>> workload and giving the clerical user a better amd more responsive
>>> experience.
>>>
>>> As some examples, my recent testing of the sales order
>>> functionality shows
>>> that it takes ~ 200 msecs to complete the "userLogin" service or
>>> 120 msecs
>>> to complete "calculateProductPrice" (these numbers are from the
>>> ofbiz log
>>> file on a fairly fast machine with lots of debug output).  If this
>>> is all
>>> done on the main ofbiz servers about 5 of the former and 10 of the
>>> later can
>>> be done simultaneously to maintain a reasonable lag time.  If the
>>> load is
>>> spread out among say 8 desktops and 2 browser accesses, everyone  has a
>>> really good experience.
>>>
>>> The only drawback to this all is that if the server configuration
>>> changes,
>>> the desktops must be patched as well.  In practice, that is not a
>>> big issue.
>>>
>>> So, it makes great sense to me to write desktop applications for
>>> common
>>> backoffice functions.
>>>
>>> I am currently working on a suite of such applications, hence my
>>> interest in
>>> BJs SWT based CRM.
>>>
>>> Skip
>>>
>>> -----Original Message-----
>>> From: David E Jones [mailto:jonesde@hotwaxmedia.com]
>>> Sent: Wednesday, October 03, 2007 11:12 AM
>>> To: user@ofbiz.apache.org
>>> Subject: Re: CRM - Customer Relationship Management facilities in
>>> OFBiz
>>>
>>>
>>>
>>> I'm not sure where this thread is leading or how it's related to
>>> OFBiz...
>>>
>>> In any case, there is CRM functionality in OFBiz. The first step
>>> would be defining in a little more detail what you mean by "CRM"
>>> since that means very different things in different companies. OFBiz
>>> does offer a single view into customer interactions including web
>>> site visits, phone/email/in-person/etc communications, requests,
>>> quotes, orders, shipments, invoices, payments, balance accounts,
>>> projects, calendar events, and many other things. You can also
>>> classify parties for marketing and sales, and do things like
>>> marketing campaigns including reference codes via email, snail mail,
>>> whatever.
>>>
>>> If you're looking for simple desktop contact management something
>>> like ACT or even salesforce.com would be better. If you're looking
>>> for enterprise CRM (especially a business or industry specific
>>> incarnation of such) then OFBiz a great basis for the effort.
>>>
>>> -David
>>>
>>>
>>> On Oct 3, 2007, at 11:07 AM, skip@theDevers wrote:
>>>
>>>> I'd like to see the SWT code as it is.  To heck with translating it
>>>> to use
>>>> web based widgets.
>>>>
>>>> I gotta set up a web site soon to hold code like this.
>>>>
>>>> Skip
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: BJ Freeman [mailto:bjfree@free-man.net]
>>>> Sent: Wednesday, October 03, 2007 3:06 AM
>>>> To: user@ofbiz.apache.org
>>>> Subject: Re: CRM - Customer Relationship Management facilities in
>>>> OFBiz
>>>>
>>>>
>>>> basically yes.
>>>> the tool i used added some classes to better manage things.
>>>> http://www.elance.com/p/?
>>>> q=eolproviderprofile&view_person=BJFreeman&catid=10
>>>> 182#tab=1
>>>> click on Java CRM
>>>>
>>>> skip@theDevers sent the following on 10/2/2007 8:55 PM:
>>>>
>>>>> BJ
>>>>>
>>>>> SWT as in Eclipse SWT?
>>>>>
>>>>> Skip
>>>>>
>>>>> -----Original Message-----
>>>>> From: BJ Freeman [mailto:bjfree@free-man.net]
>>>>> Sent: Tuesday, October 02, 2007 8:26 PM
>>>>> To: user@ofbiz.apache.org
>>>>> Subject: Re: CRM - Customer Relationship Management facilities in
>>>>> OFBiz
>>>>>
>>>>>
>>>>> there at least two efforts going that i know of.
>>>>> the data model pretty much has all that you need.
>>>>> Si's implementation does not totally integrate with the current  data
>>>>> storage. it is built on ofbiz but is supported under opentaps.
>>>>> Mine is something I am bringing over from Java SWT and SQL db.
>>>>> Once I figure out how to show the UI I want in widgets I will
>>>>> release
>>>>> it. Currently for my clients I use a java sWT that connects to
>>>>> ofbiz.
>>>>> It is built entirely within the current ofbiz datamodel.
>>>>> as soon as I get some irons of the fire will focus on it more
>>>>>
>>>>>
>>>>>
>>>>> Philip Laing sent the following on 10/2/2007 7:36 PM:
>>>>>
>>>>>> Thanks for your input relating my previous questions, I am
>>>>>> interested in
>>>>>> implementing some sort of Helpdesk/CRM system and I am interested
>>>>>> in what
>>>>>> facilities OFBiz already has
>>>>>>
>>>>>> Thanks
>>>>>> Phil
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>

Re: CRM - Customer Relationship Management facilities in OFBiz

Posted by David E Jones <jo...@hotwaxmedia.com>.

On a decent 2 processor server a fairly normal load is around 100-200  
active threads.

BTW, I just re-read what I wrote and I noticed I said "you" a lot,  
but I didn't mean you personally, substituting "one" would be more of  
what I meant. The interesting thing about all of that is that most  
people are surprised by the results and what actually makes things  
slow unless they've been through a number of performance reviews and  
optimization efforts, and that for a specific type of application.

-David


On Oct 3, 2007, at 3:16 PM, skip@theDevers wrote:

> David
>
> Thanks for the input.  As far as the "create/maintain/deploy" part,  
> I think
> I have a handle on that and am comfortable with the issues involved.
> However, I must bow to your experience on "surprised by how capable  
> servers
> are of  handling concurrent load" part as I have done no testing on  
> this at
> all and am therefore just making extrapolations based on single  
> user usage.
>
> Any insite that you have regarding the number of concurrent users  
> per server
> box would be appreciated. I would hate to get too far down this  
> road I am on
> only to discover that it was a waste of time.
>
> Skip
>
> -----Original Message-----
> From: David E Jones [mailto:jonesde@hotwaxmedia.com]
> Sent: Wednesday, October 03, 2007 1:09 PM
> To: user@ofbiz.apache.org
> Subject: Re: CRM - Customer Relationship Management facilities in  
> OFBiz
>
>
>
> You might be surprised by how expensive such a solution would be to
> create/maintain/deploy and how little it will help on server
> resources. You might also be surprised by how capable servers are of
> handling concurrent load, how different performance tends to be in a
> development versus production environment, and for certain things how
> easy it is to tune them once the slowest stuff has been identified.
>
> -David
>
>
> On Oct 3, 2007, at 1:05 PM, skip@theDevers wrote:
>
>> David
>>
>> This issue here to me asset utilization.  In a typical mid-sized
>> company,
>> there are dozens or hundreds of desktop computers that their user
>> use to do
>> their daily work.  If the user is using a browser to access logic
>> on one of
>> Ofbiz servers, the desktop is under-utilized.  By tying in a desktop
>> application to Ofbiz (i.e. running an entity engine on the desktop
>> tied to
>> the same database as the main ofbiz servers and running xml setups
>> identical
>> to the servers), that workload is performed on the users desktop
>> and not on
>> the main ofbiz servers thereby freeing the server for functionality
>> that
>> REQUIRES browser based access.
>>
>> This does not in any way supplant Ofbiz, it enhances it by
>> distributing the
>> workload and giving the clerical user a better amd more responsive
>> experience.
>>
>> As some examples, my recent testing of the sales order
>> functionality shows
>> that it takes ~ 200 msecs to complete the "userLogin" service or
>> 120 msecs
>> to complete "calculateProductPrice" (these numbers are from the
>> ofbiz log
>> file on a fairly fast machine with lots of debug output).  If this
>> is all
>> done on the main ofbiz servers about 5 of the former and 10 of the
>> later can
>> be done simultaneously to maintain a reasonable lag time.  If the
>> load is
>> spread out among say 8 desktops and 2 browser accesses, everyone  
>> has a
>> really good experience.
>>
>> The only drawback to this all is that if the server configuration
>> changes,
>> the desktops must be patched as well.  In practice, that is not a
>> big issue.
>>
>> So, it makes great sense to me to write desktop applications for
>> common
>> backoffice functions.
>>
>> I am currently working on a suite of such applications, hence my
>> interest in
>> BJs SWT based CRM.
>>
>> Skip
>>
>> -----Original Message-----
>> From: David E Jones [mailto:jonesde@hotwaxmedia.com]
>> Sent: Wednesday, October 03, 2007 11:12 AM
>> To: user@ofbiz.apache.org
>> Subject: Re: CRM - Customer Relationship Management facilities in
>> OFBiz
>>
>>
>>
>> I'm not sure where this thread is leading or how it's related to
>> OFBiz...
>>
>> In any case, there is CRM functionality in OFBiz. The first step
>> would be defining in a little more detail what you mean by "CRM"
>> since that means very different things in different companies. OFBiz
>> does offer a single view into customer interactions including web
>> site visits, phone/email/in-person/etc communications, requests,
>> quotes, orders, shipments, invoices, payments, balance accounts,
>> projects, calendar events, and many other things. You can also
>> classify parties for marketing and sales, and do things like
>> marketing campaigns including reference codes via email, snail mail,
>> whatever.
>>
>> If you're looking for simple desktop contact management something
>> like ACT or even salesforce.com would be better. If you're looking
>> for enterprise CRM (especially a business or industry specific
>> incarnation of such) then OFBiz a great basis for the effort.
>>
>> -David
>>
>>
>> On Oct 3, 2007, at 11:07 AM, skip@theDevers wrote:
>>
>>> I'd like to see the SWT code as it is.  To heck with translating it
>>> to use
>>> web based widgets.
>>>
>>> I gotta set up a web site soon to hold code like this.
>>>
>>> Skip
>>>
>>>
>>> -----Original Message-----
>>> From: BJ Freeman [mailto:bjfree@free-man.net]
>>> Sent: Wednesday, October 03, 2007 3:06 AM
>>> To: user@ofbiz.apache.org
>>> Subject: Re: CRM - Customer Relationship Management facilities in
>>> OFBiz
>>>
>>>
>>> basically yes.
>>> the tool i used added some classes to better manage things.
>>> http://www.elance.com/p/?
>>> q=eolproviderprofile&view_person=BJFreeman&catid=10
>>> 182#tab=1
>>> click on Java CRM
>>>
>>> skip@theDevers sent the following on 10/2/2007 8:55 PM:
>>>> BJ
>>>>
>>>> SWT as in Eclipse SWT?
>>>>
>>>> Skip
>>>>
>>>> -----Original Message-----
>>>> From: BJ Freeman [mailto:bjfree@free-man.net]
>>>> Sent: Tuesday, October 02, 2007 8:26 PM
>>>> To: user@ofbiz.apache.org
>>>> Subject: Re: CRM - Customer Relationship Management facilities in
>>>> OFBiz
>>>>
>>>>
>>>> there at least two efforts going that i know of.
>>>> the data model pretty much has all that you need.
>>>> Si's implementation does not totally integrate with the current  
>>>> data
>>>> storage. it is built on ofbiz but is supported under opentaps.
>>>> Mine is something I am bringing over from Java SWT and SQL db.
>>>> Once I figure out how to show the UI I want in widgets I will
>>>> release
>>>> it. Currently for my clients I use a java sWT that connects to
>>>> ofbiz.
>>>> It is built entirely within the current ofbiz datamodel.
>>>> as soon as I get some irons of the fire will focus on it more
>>>>
>>>>
>>>>
>>>> Philip Laing sent the following on 10/2/2007 7:36 PM:
>>>>> Thanks for your input relating my previous questions, I am
>>>>> interested in
>>>>> implementing some sort of Helpdesk/CRM system and I am interested
>>>>> in what
>>>>> facilities OFBiz already has
>>>>>
>>>>> Thanks
>>>>> Phil
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>
>

RE: CRM - Customer Relationship Management facilities in OFBiz

Posted by "skip@theDevers" <sk...@thedevers.org>.

David

Thanks for the input.  As far as the "create/maintain/deploy" part, I think
I have a handle on that and am comfortable with the issues involved.
However, I must bow to your experience on "surprised by how capable servers
are of  handling concurrent load" part as I have done no testing on this at
all and am therefore just making extrapolations based on single user usage.

Any insite that you have regarding the number of concurrent users per server
box would be appreciated. I would hate to get too far down this road I am on
only to discover that it was a waste of time.

Skip

-----Original Message-----
From: David E Jones [mailto:jonesde@hotwaxmedia.com]
Sent: Wednesday, October 03, 2007 1:09 PM
To: user@ofbiz.apache.org
Subject: Re: CRM - Customer Relationship Management facilities in OFBiz



You might be surprised by how expensive such a solution would be to
create/maintain/deploy and how little it will help on server
resources. You might also be surprised by how capable servers are of
handling concurrent load, how different performance tends to be in a
development versus production environment, and for certain things how
easy it is to tune them once the slowest stuff has been identified.

-David


On Oct 3, 2007, at 1:05 PM, skip@theDevers wrote:

> David
>
> This issue here to me asset utilization.  In a typical mid-sized
> company,
> there are dozens or hundreds of desktop computers that their user
> use to do
> their daily work.  If the user is using a browser to access logic
> on one of
> Ofbiz servers, the desktop is under-utilized.  By tying in a desktop
> application to Ofbiz (i.e. running an entity engine on the desktop
> tied to
> the same database as the main ofbiz servers and running xml setups
> identical
> to the servers), that workload is performed on the users desktop
> and not on
> the main ofbiz servers thereby freeing the server for functionality
> that
> REQUIRES browser based access.
>
> This does not in any way supplant Ofbiz, it enhances it by
> distributing the
> workload and giving the clerical user a better amd more responsive
> experience.
>
> As some examples, my recent testing of the sales order
> functionality shows
> that it takes ~ 200 msecs to complete the "userLogin" service or
> 120 msecs
> to complete "calculateProductPrice" (these numbers are from the
> ofbiz log
> file on a fairly fast machine with lots of debug output).  If this
> is all
> done on the main ofbiz servers about 5 of the former and 10 of the
> later can
> be done simultaneously to maintain a reasonable lag time.  If the
> load is
> spread out among say 8 desktops and 2 browser accesses, everyone has a
> really good experience.
>
> The only drawback to this all is that if the server configuration
> changes,
> the desktops must be patched as well.  In practice, that is not a
> big issue.
>
> So, it makes great sense to me to write desktop applications for
> common
> backoffice functions.
>
> I am currently working on a suite of such applications, hence my
> interest in
> BJs SWT based CRM.
>
> Skip
>
> -----Original Message-----
> From: David E Jones [mailto:jonesde@hotwaxmedia.com]
> Sent: Wednesday, October 03, 2007 11:12 AM
> To: user@ofbiz.apache.org
> Subject: Re: CRM - Customer Relationship Management facilities in
> OFBiz
>
>
>
> I'm not sure where this thread is leading or how it's related to
> OFBiz...
>
> In any case, there is CRM functionality in OFBiz. The first step
> would be defining in a little more detail what you mean by "CRM"
> since that means very different things in different companies. OFBiz
> does offer a single view into customer interactions including web
> site visits, phone/email/in-person/etc communications, requests,
> quotes, orders, shipments, invoices, payments, balance accounts,
> projects, calendar events, and many other things. You can also
> classify parties for marketing and sales, and do things like
> marketing campaigns including reference codes via email, snail mail,
> whatever.
>
> If you're looking for simple desktop contact management something
> like ACT or even salesforce.com would be better. If you're looking
> for enterprise CRM (especially a business or industry specific
> incarnation of such) then OFBiz a great basis for the effort.
>
> -David
>
>
> On Oct 3, 2007, at 11:07 AM, skip@theDevers wrote:
>
>> I'd like to see the SWT code as it is.  To heck with translating it
>> to use
>> web based widgets.
>>
>> I gotta set up a web site soon to hold code like this.
>>
>> Skip
>>
>>
>> -----Original Message-----
>> From: BJ Freeman [mailto:bjfree@free-man.net]
>> Sent: Wednesday, October 03, 2007 3:06 AM
>> To: user@ofbiz.apache.org
>> Subject: Re: CRM - Customer Relationship Management facilities in
>> OFBiz
>>
>>
>> basically yes.
>> the tool i used added some classes to better manage things.
>> http://www.elance.com/p/?
>> q=eolproviderprofile&view_person=BJFreeman&catid=10
>> 182#tab=1
>> click on Java CRM
>>
>> skip@theDevers sent the following on 10/2/2007 8:55 PM:
>>> BJ
>>>
>>> SWT as in Eclipse SWT?
>>>
>>> Skip
>>>
>>> -----Original Message-----
>>> From: BJ Freeman [mailto:bjfree@free-man.net]
>>> Sent: Tuesday, October 02, 2007 8:26 PM
>>> To: user@ofbiz.apache.org
>>> Subject: Re: CRM - Customer Relationship Management facilities in
>>> OFBiz
>>>
>>>
>>> there at least two efforts going that i know of.
>>> the data model pretty much has all that you need.
>>> Si's implementation does not totally integrate with the current data
>>> storage. it is built on ofbiz but is supported under opentaps.
>>> Mine is something I am bringing over from Java SWT and SQL db.
>>> Once I figure out how to show the UI I want in widgets I will
>>> release
>>> it. Currently for my clients I use a java sWT that connects to
>>> ofbiz.
>>> It is built entirely within the current ofbiz datamodel.
>>> as soon as I get some irons of the fire will focus on it more
>>>
>>>
>>>
>>> Philip Laing sent the following on 10/2/2007 7:36 PM:
>>>> Thanks for your input relating my previous questions, I am
>>>> interested in
>>>> implementing some sort of Helpdesk/CRM system and I am interested
>>>> in what
>>>> facilities OFBiz already has
>>>>
>>>> Thanks
>>>> Phil
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>
>

Re: CRM - Customer Relationship Management facilities in OFBiz

Posted by David E Jones <jo...@hotwaxmedia.com>.

You might be surprised by how expensive such a solution would be to  
create/maintain/deploy and how little it will help on server  
resources. You might also be surprised by how capable servers are of  
handling concurrent load, how different performance tends to be in a  
development versus production environment, and for certain things how  
easy it is to tune them once the slowest stuff has been identified.

-David


On Oct 3, 2007, at 1:05 PM, skip@theDevers wrote:

> David
>
> This issue here to me asset utilization.  In a typical mid-sized  
> company,
> there are dozens or hundreds of desktop computers that their user  
> use to do
> their daily work.  If the user is using a browser to access logic  
> on one of
> Ofbiz servers, the desktop is under-utilized.  By tying in a desktop
> application to Ofbiz (i.e. running an entity engine on the desktop  
> tied to
> the same database as the main ofbiz servers and running xml setups  
> identical
> to the servers), that workload is performed on the users desktop  
> and not on
> the main ofbiz servers thereby freeing the server for functionality  
> that
> REQUIRES browser based access.
>
> This does not in any way supplant Ofbiz, it enhances it by  
> distributing the
> workload and giving the clerical user a better amd more responsive
> experience.
>
> As some examples, my recent testing of the sales order  
> functionality shows
> that it takes ~ 200 msecs to complete the "userLogin" service or  
> 120 msecs
> to complete "calculateProductPrice" (these numbers are from the  
> ofbiz log
> file on a fairly fast machine with lots of debug output).  If this  
> is all
> done on the main ofbiz servers about 5 of the former and 10 of the  
> later can
> be done simultaneously to maintain a reasonable lag time.  If the  
> load is
> spread out among say 8 desktops and 2 browser accesses, everyone has a
> really good experience.
>
> The only drawback to this all is that if the server configuration  
> changes,
> the desktops must be patched as well.  In practice, that is not a  
> big issue.
>
> So, it makes great sense to me to write desktop applications for  
> common
> backoffice functions.
>
> I am currently working on a suite of such applications, hence my  
> interest in
> BJs SWT based CRM.
>
> Skip
>
> -----Original Message-----
> From: David E Jones [mailto:jonesde@hotwaxmedia.com]
> Sent: Wednesday, October 03, 2007 11:12 AM
> To: user@ofbiz.apache.org
> Subject: Re: CRM - Customer Relationship Management facilities in  
> OFBiz
>
>
>
> I'm not sure where this thread is leading or how it's related to
> OFBiz...
>
> In any case, there is CRM functionality in OFBiz. The first step
> would be defining in a little more detail what you mean by "CRM"
> since that means very different things in different companies. OFBiz
> does offer a single view into customer interactions including web
> site visits, phone/email/in-person/etc communications, requests,
> quotes, orders, shipments, invoices, payments, balance accounts,
> projects, calendar events, and many other things. You can also
> classify parties for marketing and sales, and do things like
> marketing campaigns including reference codes via email, snail mail,
> whatever.
>
> If you're looking for simple desktop contact management something
> like ACT or even salesforce.com would be better. If you're looking
> for enterprise CRM (especially a business or industry specific
> incarnation of such) then OFBiz a great basis for the effort.
>
> -David
>
>
> On Oct 3, 2007, at 11:07 AM, skip@theDevers wrote:
>
>> I'd like to see the SWT code as it is.  To heck with translating it
>> to use
>> web based widgets.
>>
>> I gotta set up a web site soon to hold code like this.
>>
>> Skip
>>
>>
>> -----Original Message-----
>> From: BJ Freeman [mailto:bjfree@free-man.net]
>> Sent: Wednesday, October 03, 2007 3:06 AM
>> To: user@ofbiz.apache.org
>> Subject: Re: CRM - Customer Relationship Management facilities in
>> OFBiz
>>
>>
>> basically yes.
>> the tool i used added some classes to better manage things.
>> http://www.elance.com/p/?
>> q=eolproviderprofile&view_person=BJFreeman&catid=10
>> 182#tab=1
>> click on Java CRM
>>
>> skip@theDevers sent the following on 10/2/2007 8:55 PM:
>>> BJ
>>>
>>> SWT as in Eclipse SWT?
>>>
>>> Skip
>>>
>>> -----Original Message-----
>>> From: BJ Freeman [mailto:bjfree@free-man.net]
>>> Sent: Tuesday, October 02, 2007 8:26 PM
>>> To: user@ofbiz.apache.org
>>> Subject: Re: CRM - Customer Relationship Management facilities in
>>> OFBiz
>>>
>>>
>>> there at least two efforts going that i know of.
>>> the data model pretty much has all that you need.
>>> Si's implementation does not totally integrate with the current data
>>> storage. it is built on ofbiz but is supported under opentaps.
>>> Mine is something I am bringing over from Java SWT and SQL db.
>>> Once I figure out how to show the UI I want in widgets I will  
>>> release
>>> it. Currently for my clients I use a java sWT that connects to  
>>> ofbiz.
>>> It is built entirely within the current ofbiz datamodel.
>>> as soon as I get some irons of the fire will focus on it more
>>>
>>>
>>>
>>> Philip Laing sent the following on 10/2/2007 7:36 PM:
>>>> Thanks for your input relating my previous questions, I am
>>>> interested in
>>>> implementing some sort of Helpdesk/CRM system and I am interested
>>>> in what
>>>> facilities OFBiz already has
>>>>
>>>> Thanks
>>>> Phil
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>
>

RE: CRM - Customer Relationship Management facilities in OFBiz

Posted by "skip@theDevers" <sk...@thedevers.org>.

David

This issue here to me asset utilization.  In a typical mid-sized company,
there are dozens or hundreds of desktop computers that their user use to do
their daily work.  If the user is using a browser to access logic on one of
Ofbiz servers, the desktop is under-utilized.  By tying in a desktop
application to Ofbiz (i.e. running an entity engine on the desktop tied to
the same database as the main ofbiz servers and running xml setups identical
to the servers), that workload is performed on the users desktop and not on
the main ofbiz servers thereby freeing the server for functionality that
REQUIRES browser based access.

This does not in any way supplant Ofbiz, it enhances it by distributing the
workload and giving the clerical user a better amd more responsive
experience.

As some examples, my recent testing of the sales order functionality shows
that it takes ~ 200 msecs to complete the "userLogin" service or 120 msecs
to complete "calculateProductPrice" (these numbers are from the ofbiz log
file on a fairly fast machine with lots of debug output).  If this is all
done on the main ofbiz servers about 5 of the former and 10 of the later can
be done simultaneously to maintain a reasonable lag time.  If the load is
spread out among say 8 desktops and 2 browser accesses, everyone has a
really good experience.

The only drawback to this all is that if the server configuration changes,
the desktops must be patched as well.  In practice, that is not a big issue.

So, it makes great sense to me to write desktop applications for common
backoffice functions.

I am currently working on a suite of such applications, hence my interest in
BJs SWT based CRM.

Skip

-----Original Message-----
From: David E Jones [mailto:jonesde@hotwaxmedia.com]
Sent: Wednesday, October 03, 2007 11:12 AM
To: user@ofbiz.apache.org
Subject: Re: CRM - Customer Relationship Management facilities in OFBiz

I'm not sure where this thread is leading or how it's related to
OFBiz...

In any case, there is CRM functionality in OFBiz. The first step
would be defining in a little more detail what you mean by "CRM"
since that means very different things in different companies. OFBiz
does offer a single view into customer interactions including web
site visits, phone/email/in-person/etc communications, requests,
quotes, orders, shipments, invoices, payments, balance accounts,
projects, calendar events, and many other things. You can also
classify parties for marketing and sales, and do things like
marketing campaigns including reference codes via email, snail mail,
whatever.

If you're looking for simple desktop contact management something
like ACT or even salesforce.com would be better. If you're looking
for enterprise CRM (especially a business or industry specific
incarnation of such) then OFBiz a great basis for the effort.

-David

On Oct 3, 2007, at 11:07 AM, skip@theDevers wrote:

> I'd like to see the SWT code as it is.  To heck with translating it
> to use
> web based widgets.
>
> I gotta set up a web site soon to hold code like this.
>
> Skip
>
>
> -----Original Message-----
> From: BJ Freeman [mailto:bjfree@free-man.net]
> Sent: Wednesday, October 03, 2007 3:06 AM
> To: user@ofbiz.apache.org
> Subject: Re: CRM - Customer Relationship Management facilities in
> OFBiz
>
>
> basically yes.
> the tool i used added some classes to better manage things.
> http://www.elance.com/p/?
> q=eolproviderprofile&view_person=BJFreeman&catid=10
> 182#tab=1
> click on Java CRM
>
> skip@theDevers sent the following on 10/2/2007 8:55 PM:
>> BJ
>>
>> SWT as in Eclipse SWT?
>>
>> Skip
>>
>> -----Original Message-----
>> From: BJ Freeman [mailto:bjfree@free-man.net]
>> Sent: Tuesday, October 02, 2007 8:26 PM
>> To: user@ofbiz.apache.org
>> Subject: Re: CRM - Customer Relationship Management facilities in
>> OFBiz
>>
>>
>> there at least two efforts going that i know of.
>> the data model pretty much has all that you need.
>> Si's implementation does not totally integrate with the current data
>> storage. it is built on ofbiz but is supported under opentaps.
>> Mine is something I am bringing over from Java SWT and SQL db.
>> Once I figure out how to show the UI I want in widgets I will release
>> it. Currently for my clients I use a java sWT that connects to ofbiz.
>> It is built entirely within the current ofbiz datamodel.
>> as soon as I get some irons of the fire will focus on it more
>>
>>
>>
>> Philip Laing sent the following on 10/2/2007 7:36 PM:
>>> Thanks for your input relating my previous questions, I am
>>> interested in
>>> implementing some sort of Helpdesk/CRM system and I am interested
>>> in what
>>> facilities OFBiz already has
>>>
>>> Thanks
>>> Phil
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>

Re: CRM - Customer Relationship Management facilities in OFBiz

Posted by David E Jones <jo...@hotwaxmedia.com>.

I'm not sure where this thread is leading or how it's related to  
OFBiz...

In any case, there is CRM functionality in OFBiz. The first step  
would be defining in a little more detail what you mean by "CRM"  
since that means very different things in different companies. OFBiz  
does offer a single view into customer interactions including web  
site visits, phone/email/in-person/etc communications, requests,  
quotes, orders, shipments, invoices, payments, balance accounts,  
projects, calendar events, and many other things. You can also  
classify parties for marketing and sales, and do things like  
marketing campaigns including reference codes via email, snail mail,  
whatever.

If you're looking for simple desktop contact management something  
like ACT or even salesforce.com would be better. If you're looking  
for enterprise CRM (especially a business or industry specific  
incarnation of such) then OFBiz a great basis for the effort.

-David

On Oct 3, 2007, at 11:07 AM, skip@theDevers wrote:

> I'd like to see the SWT code as it is.  To heck with translating it  
> to use
> web based widgets.
>
> I gotta set up a web site soon to hold code like this.
>
> Skip
>
>
> -----Original Message-----
> From: BJ Freeman [mailto:bjfree@free-man.net]
> Sent: Wednesday, October 03, 2007 3:06 AM
> To: user@ofbiz.apache.org
> Subject: Re: CRM - Customer Relationship Management facilities in  
> OFBiz
>
>
> basically yes.
> the tool i used added some classes to better manage things.
> http://www.elance.com/p/? 
> q=eolproviderprofile&view_person=BJFreeman&catid=10
> 182#tab=1
> click on Java CRM
>
> skip@theDevers sent the following on 10/2/2007 8:55 PM:
>> BJ
>>
>> SWT as in Eclipse SWT?
>>
>> Skip
>>
>> -----Original Message-----
>> From: BJ Freeman [mailto:bjfree@free-man.net]
>> Sent: Tuesday, October 02, 2007 8:26 PM
>> To: user@ofbiz.apache.org
>> Subject: Re: CRM - Customer Relationship Management facilities in  
>> OFBiz
>>
>>
>> there at least two efforts going that i know of.
>> the data model pretty much has all that you need.
>> Si's implementation does not totally integrate with the current data
>> storage. it is built on ofbiz but is supported under opentaps.
>> Mine is something I am bringing over from Java SWT and SQL db.
>> Once I figure out how to show the UI I want in widgets I will release
>> it. Currently for my clients I use a java sWT that connects to ofbiz.
>> It is built entirely within the current ofbiz datamodel.
>> as soon as I get some irons of the fire will focus on it more
>>
>>
>>
>> Philip Laing sent the following on 10/2/2007 7:36 PM:
>>> Thanks for your input relating my previous questions, I am  
>>> interested in
>>> implementing some sort of Helpdesk/CRM system and I am interested  
>>> in what
>>> facilities OFBiz already has
>>>
>>> Thanks
>>> Phil
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>

RE: CRM - Customer Relationship Management facilities in OFBiz

Posted by "skip@theDevers" <sk...@thedevers.org>.

I'd like to see the SWT code as it is.  To heck with translating it to use
web based widgets.

I gotta set up a web site soon to hold code like this.

Skip


-----Original Message-----
From: BJ Freeman [mailto:bjfree@free-man.net]
Sent: Wednesday, October 03, 2007 3:06 AM
To: user@ofbiz.apache.org
Subject: Re: CRM - Customer Relationship Management facilities in OFBiz


basically yes.
the tool i used added some classes to better manage things.
http://www.elance.com/p/?q=eolproviderprofile&view_person=BJFreeman&catid=10
182#tab=1
click on Java CRM

skip@theDevers sent the following on 10/2/2007 8:55 PM:
> BJ
>
> SWT as in Eclipse SWT?
>
> Skip
>
> -----Original Message-----
> From: BJ Freeman [mailto:bjfree@free-man.net]
> Sent: Tuesday, October 02, 2007 8:26 PM
> To: user@ofbiz.apache.org
> Subject: Re: CRM - Customer Relationship Management facilities in OFBiz
>
>
> there at least two efforts going that i know of.
> the data model pretty much has all that you need.
> Si's implementation does not totally integrate with the current data
> storage. it is built on ofbiz but is supported under opentaps.
> Mine is something I am bringing over from Java SWT and SQL db.
> Once I figure out how to show the UI I want in widgets I will release
> it. Currently for my clients I use a java sWT that connects to ofbiz.
> It is built entirely within the current ofbiz datamodel.
> as soon as I get some irons of the fire will focus on it more
>
>
>
> Philip Laing sent the following on 10/2/2007 7:36 PM:
>> Thanks for your input relating my previous questions, I am interested in
>> implementing some sort of Helpdesk/CRM system and I am interested in what
>> facilities OFBiz already has
>>
>> Thanks
>> Phil
>>
>>
>>
>>
>
>
>
>

Re: CRM - Customer Relationship Management facilities in OFBiz

Posted by BJ Freeman <bj...@free-man.net>.

basically yes.
the tool i used added some classes to better manage things.
http://www.elance.com/p/?q=eolproviderprofile&view_person=BJFreeman&catid=10182#tab=1
click on Java CRM

skip@theDevers sent the following on 10/2/2007 8:55 PM:
> BJ 
> 
> SWT as in Eclipse SWT?
> 
> Skip
> 
> -----Original Message-----
> From: BJ Freeman [mailto:bjfree@free-man.net]
> Sent: Tuesday, October 02, 2007 8:26 PM
> To: user@ofbiz.apache.org
> Subject: Re: CRM - Customer Relationship Management facilities in OFBiz
> 
> 
> there at least two efforts going that i know of.
> the data model pretty much has all that you need.
> Si's implementation does not totally integrate with the current data
> storage. it is built on ofbiz but is supported under opentaps.
> Mine is something I am bringing over from Java SWT and SQL db.
> Once I figure out how to show the UI I want in widgets I will release
> it. Currently for my clients I use a java sWT that connects to ofbiz.
> It is built entirely within the current ofbiz datamodel.
> as soon as I get some irons of the fire will focus on it more
> 
> 
> 
> Philip Laing sent the following on 10/2/2007 7:36 PM:
>> Thanks for your input relating my previous questions, I am interested in
>> implementing some sort of Helpdesk/CRM system and I am interested in what
>> facilities OFBiz already has
>>  
>> Thanks
>> Phil
>>
>>
>>
>>
> 
> 
> 
>

RE: CRM - Customer Relationship Management facilities in OFBiz

Posted by "skip@theDevers" <sk...@thedevers.org>.

BJ 

SWT as in Eclipse SWT?

Skip

-----Original Message-----
From: BJ Freeman [mailto:bjfree@free-man.net]
Sent: Tuesday, October 02, 2007 8:26 PM
To: user@ofbiz.apache.org
Subject: Re: CRM - Customer Relationship Management facilities in OFBiz

there at least two efforts going that i know of.
the data model pretty much has all that you need.
Si's implementation does not totally integrate with the current data
storage. it is built on ofbiz but is supported under opentaps.
Mine is something I am bringing over from Java SWT and SQL db.
Once I figure out how to show the UI I want in widgets I will release
it. Currently for my clients I use a java sWT that connects to ofbiz.
It is built entirely within the current ofbiz datamodel.
as soon as I get some irons of the fire will focus on it more

Philip Laing sent the following on 10/2/2007 7:36 PM:
> Thanks for your input relating my previous questions, I am interested in
> implementing some sort of Helpdesk/CRM system and I am interested in what
> facilities OFBiz already has
>  
> Thanks
> Phil
> 
> 
> 
>

Re: CRM - Customer Relationship Management facilities in OFBiz

Posted by BJ Freeman <bj...@free-man.net>.

there at least two efforts going that i know of.
the data model pretty much has all that you need.
Si's implementation does not totally integrate with the current data
storage. it is built on ofbiz but is supported under opentaps.
Mine is something I am bringing over from Java SWT and SQL db.
Once I figure out how to show the UI I want in widgets I will release
it. Currently for my clients I use a java sWT that connects to ofbiz.
It is built entirely within the current ofbiz datamodel.
as soon as I get some irons of the fire will focus on it more



Philip Laing sent the following on 10/2/2007 7:36 PM:
> Thanks for your input relating my previous questions, I am interested in
> implementing some sort of Helpdesk/CRM system and I am interested in what
> facilities OFBiz already has
>  
> Thanks
> Phil
> 
> 
> 
>

CRM - Customer Relationship Management facilities in OFBiz

Posted by Philip Laing <ph...@ascconsultants.com.au>.

Thanks for your input relating my previous questions, I am interested in
implementing some sort of Helpdesk/CRM system and I am interested in what
facilities OFBiz already has
 
Thanks
Phil

RE: Linux distro?

Posted by "skip@theDevers" <sk...@thedevers.org>.

Jonathon

Once again, thanks for the insite.

Skip

-----Original Message-----
From: Jonathon -- Improov [mailto:jonw@improov.com]
Sent: Tuesday, October 02, 2007 7:27 PM
To: user@ofbiz.apache.org
Subject: Re: Linux distro?


A couple of clients I have use 64-bit AMD machines. I recall there weren't
any official Sun SDKs
supporting those machines. My clients were forced to use some other non-Sun
SDKs. Not good. Lots
of bizarre issues.

As for 64-bit gotchas, I wouldn't be surprised. Newer hardwares often have
new problems. I try to
go with mainstream models. Cluster up a few mainstream workhorses if we need
more power.

Jonathon

Skip wrote:
> BJ
>
> Thats a good idea, I would be particularly happy to hear about 64 bit
> gotchas.  I seem to remember hearing about memory > 2gigs causing a
problem
> with multiple CPUs and > 2gigs of memory or some such.
>
> Skip
>
> -----Original Message-----
> From: BJ Freeman [mailto:bjfree@free-man.net]
> Sent: Tuesday, October 02, 2007 9:30 AM
> To: user@ofbiz.apache.org
> Subject: Re: Linux distro?
>
>
> The only condsideration is if the distro you your plan to use supports
> Sun SDK package.
> as long as you have 1.5 or better on you box then you ok.
> Fedora installs the opensource SDK and yum does not work to get the sun
SDK.
>
> Maybe we should put a doc file up that everyone can put what distro they
> have tried and if they were sucessful or not.
>
>
>
> clearchris sent the following on 10/2/2007 8:41 AM:
>> I plan on running Gentoo, though many disagree with that choice.
>>
>> http://linux.slashdot.org/linux/07/01/28/2227232.shtml
>>
>> I find that using the stable (non ~) branch with occasional upgrades to
> ~x86
>> (unstable) programs runs quite well.  It's the best of both worlds IMHO,
> you
>> can get the stable software and you can get the newer fixes that you
>> inevitably will need.  Best of all, it provides a nice framework for
>> managing that complexity.
>>
>> If you plan on using the POS application under linux, I'd highly suggest
>> using a 32 bit distribution, even if you have a 64 bit processor.  Most
>> (nearly all it seems) JavaPOS drivers have a native binary component that
> is
>> 32 bit.  While AMD processors can run 32 bit code natively, the binary
>> drivers require 32 bit system libraries, etc, which can get a bit
>> interesting to set up.
>>
>> My 2c.
>>
>> Chris
>>
>> -----Original Message-----
>> From: Philip Laing [mailto:philip.laing@ascconsultants.com.au]
>> Sent: Tuesday, October 02, 2007 12:05 AM
>> To: user@ofbiz.apache.org
>> Subject: Linux distro?
>>
>> Thanks skip - just looking at a review on CentOS at the moment.  Looks
>> fairly impressive for server stability
>>
>> cheers
>>
>> Phil
>>
>>> -----Original Message-----
>>> From: skip@theDevers [mailto:skip@thedevers.org]
>>> Sent: Tuesday, 2 October 2007 1:59 PM
>>> To: user@ofbiz.apache.org
>>> Subject: RE: Download SVN Repository ... Linux distro?
>>>
>>> Instead of Fedora Core, give a look at CentOS.  Its a good deal more
>>> stable.
>>> I have had lots of weird problems with Fedora in the past (usually fixed
>>> within a few weeks, but still a pain when it happens).
>>>
>>> Skip
>>>
>>> -----Original Message-----
>>> From: Philip Laing [mailto:philip.laing@ascconsultants.com.au]
>>> Sent: Monday, October 01, 2007 6:01 PM
>>> To: user@ofbiz.apache.org
>>> Subject: RE: Download SVN Repository ... Linux distro?
>>>
>>>
>>> Thanks BJ ... Now what distro would be more suited these days?  I am
>>> looking
>>> at Fedora or Ununtu ... some may have preferences for viable reasons
>>>
>>> Thanks again ... quick reply to my question ... I think I am going to
> like
>>> setting up and configuring OFBiz
>>>
>>> Phil
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: BJ Freeman [mailto:bjfree@free-man.net]
>>>> Sent: Tuesday, 2 October 2007 10:29 AM
>>>> To: user@ofbiz.apache.org
>>>> Subject: Re: Download SVN Repository
>>>>
>>>> first read
>>>>
> http://docs.ofbiz.org/display/OFBTECH/Apache+OFBiz+Technical+Production+Se
>>>> tup+Guide\
>>>> http://docs.ofbiz.org/display/OFBIZ/How+to+run+OFBiz+as+a+Service
>>>> may help.
>>>> then on your linux box
>>>> load svn
>>>> some use wget
>>>> then you can use the svn commands to load ofbiz.
>>>> http://docs.ofbiz.org/display/OFBADMIN/Demo+and+Test+Setup+Guide
>>>>
>>>> Philip Laing sent the following on 10/1/2007 5:06 PM:
>>>>> Hi Fellas
>>>>> I am preparing a Linux box with OFBiz + PostgreSQL ... I have had
>>>> Compiere
>>>>> and OpenBravo installed on my windows server boxes and have
>>> investigated
>>>>> TinyERP however OFBiz seems to fit in better with my business model
>>>> which
>>>>> largely consists of virtual warehousing and drop ship ecommerce.  This
>>>> is my
>>>>> first posting in this forum so excuse me if I have missed any protocol
>>>> or my
>>>>> questions seem simplistic. So here we go
>>>>>
>>>>> 1. How do I download from the required SVN repositories using windows?
>>>>> 2. Search the list archives for threads other than scrolling through
>>> one
>>>> by
>>>>> one?
>>>>>
>>>>> Thanks in advance
>>>>> Wikitec
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>
>>
>>
>>
>>
>
>

Re: Linux distro?

Posted by Jonathon -- Improov <jo...@improov.com>.

A couple of clients I have use 64-bit AMD machines. I recall there weren't any official Sun SDKs 
supporting those machines. My clients were forced to use some other non-Sun SDKs. Not good. Lots 
of bizarre issues.

As for 64-bit gotchas, I wouldn't be surprised. Newer hardwares often have new problems. I try to 
go with mainstream models. Cluster up a few mainstream workhorses if we need more power.

Jonathon

Skip wrote:
> BJ
> 
> Thats a good idea, I would be particularly happy to hear about 64 bit
> gotchas.  I seem to remember hearing about memory > 2gigs causing a problem
> with multiple CPUs and > 2gigs of memory or some such.
> 
> Skip
> 
> -----Original Message-----
> From: BJ Freeman [mailto:bjfree@free-man.net]
> Sent: Tuesday, October 02, 2007 9:30 AM
> To: user@ofbiz.apache.org
> Subject: Re: Linux distro?
> 
> 
> The only condsideration is if the distro you your plan to use supports
> Sun SDK package.
> as long as you have 1.5 or better on you box then you ok.
> Fedora installs the opensource SDK and yum does not work to get the sun SDK.
> 
> Maybe we should put a doc file up that everyone can put what distro they
> have tried and if they were sucessful or not.
> 
> 
> 
> clearchris sent the following on 10/2/2007 8:41 AM:
>> I plan on running Gentoo, though many disagree with that choice.
>>
>> http://linux.slashdot.org/linux/07/01/28/2227232.shtml
>>
>> I find that using the stable (non ~) branch with occasional upgrades to
> ~x86
>> (unstable) programs runs quite well.  It's the best of both worlds IMHO,
> you
>> can get the stable software and you can get the newer fixes that you
>> inevitably will need.  Best of all, it provides a nice framework for
>> managing that complexity.
>>
>> If you plan on using the POS application under linux, I'd highly suggest
>> using a 32 bit distribution, even if you have a 64 bit processor.  Most
>> (nearly all it seems) JavaPOS drivers have a native binary component that
> is
>> 32 bit.  While AMD processors can run 32 bit code natively, the binary
>> drivers require 32 bit system libraries, etc, which can get a bit
>> interesting to set up.
>>
>> My 2c.
>>
>> Chris
>>
>> -----Original Message-----
>> From: Philip Laing [mailto:philip.laing@ascconsultants.com.au]
>> Sent: Tuesday, October 02, 2007 12:05 AM
>> To: user@ofbiz.apache.org
>> Subject: Linux distro?
>>
>> Thanks skip - just looking at a review on CentOS at the moment.  Looks
>> fairly impressive for server stability
>>
>> cheers
>>
>> Phil
>>
>>> -----Original Message-----
>>> From: skip@theDevers [mailto:skip@thedevers.org]
>>> Sent: Tuesday, 2 October 2007 1:59 PM
>>> To: user@ofbiz.apache.org
>>> Subject: RE: Download SVN Repository ... Linux distro?
>>>
>>> Instead of Fedora Core, give a look at CentOS.  Its a good deal more
>>> stable.
>>> I have had lots of weird problems with Fedora in the past (usually fixed
>>> within a few weeks, but still a pain when it happens).
>>>
>>> Skip
>>>
>>> -----Original Message-----
>>> From: Philip Laing [mailto:philip.laing@ascconsultants.com.au]
>>> Sent: Monday, October 01, 2007 6:01 PM
>>> To: user@ofbiz.apache.org
>>> Subject: RE: Download SVN Repository ... Linux distro?
>>>
>>>
>>> Thanks BJ ... Now what distro would be more suited these days?  I am
>>> looking
>>> at Fedora or Ununtu ... some may have preferences for viable reasons
>>>
>>> Thanks again ... quick reply to my question ... I think I am going to
> like
>>> setting up and configuring OFBiz
>>>
>>> Phil
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: BJ Freeman [mailto:bjfree@free-man.net]
>>>> Sent: Tuesday, 2 October 2007 10:29 AM
>>>> To: user@ofbiz.apache.org
>>>> Subject: Re: Download SVN Repository
>>>>
>>>> first read
>>>>
> http://docs.ofbiz.org/display/OFBTECH/Apache+OFBiz+Technical+Production+Se
>>>> tup+Guide\
>>>> http://docs.ofbiz.org/display/OFBIZ/How+to+run+OFBiz+as+a+Service
>>>> may help.
>>>> then on your linux box
>>>> load svn
>>>> some use wget
>>>> then you can use the svn commands to load ofbiz.
>>>> http://docs.ofbiz.org/display/OFBADMIN/Demo+and+Test+Setup+Guide
>>>>
>>>> Philip Laing sent the following on 10/1/2007 5:06 PM:
>>>>> Hi Fellas
>>>>> I am preparing a Linux box with OFBiz + PostgreSQL ... I have had
>>>> Compiere
>>>>> and OpenBravo installed on my windows server boxes and have
>>> investigated
>>>>> TinyERP however OFBiz seems to fit in better with my business model
>>>> which
>>>>> largely consists of virtual warehousing and drop ship ecommerce.  This
>>>> is my
>>>>> first posting in this forum so excuse me if I have missed any protocol
>>>> or my
>>>>> questions seem simplistic. So here we go
>>>>>
>>>>> 1. How do I download from the required SVN repositories using windows?
>>>>> 2. Search the list archives for threads other than scrolling through
>>> one
>>>> by
>>>>> one?
>>>>>
>>>>> Thanks in advance
>>>>> Wikitec
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>
>>
>>
>>
>>
> 
>

Re: Linux distro?

Posted by BJ Freeman <bj...@free-man.net>.

Skip:
Not sure I want to open a can of worms or reporting linux problems
unless they specifically relate to ofbiz.
There are linux forums for general problems like you describe.

Skip sent the following on 10/2/2007 1:12 PM:
> BJ
> 
> Thats a good idea, I would be particularly happy to hear about 64 bit
> gotchas.  I seem to remember hearing about memory > 2gigs causing a problem
> with multiple CPUs and > 2gigs of memory or some such.
> 
> Skip
> 
> -----Original Message-----
> From: BJ Freeman [mailto:bjfree@free-man.net]
> Sent: Tuesday, October 02, 2007 9:30 AM
> To: user@ofbiz.apache.org
> Subject: Re: Linux distro?
> 
> 
> The only condsideration is if the distro you your plan to use supports
> Sun SDK package.
> as long as you have 1.5 or better on you box then you ok.
> Fedora installs the opensource SDK and yum does not work to get the sun SDK.
> 
> Maybe we should put a doc file up that everyone can put what distro they
> have tried and if they were sucessful or not.
> 
> 
> 
> clearchris sent the following on 10/2/2007 8:41 AM:
>> I plan on running Gentoo, though many disagree with that choice.
>>
>> http://linux.slashdot.org/linux/07/01/28/2227232.shtml
>>
>> I find that using the stable (non ~) branch with occasional upgrades to
> ~x86
>> (unstable) programs runs quite well.  It's the best of both worlds IMHO,
> you
>> can get the stable software and you can get the newer fixes that you
>> inevitably will need.  Best of all, it provides a nice framework for
>> managing that complexity.
>>
>> If you plan on using the POS application under linux, I'd highly suggest
>> using a 32 bit distribution, even if you have a 64 bit processor.  Most
>> (nearly all it seems) JavaPOS drivers have a native binary component that
> is
>> 32 bit.  While AMD processors can run 32 bit code natively, the binary
>> drivers require 32 bit system libraries, etc, which can get a bit
>> interesting to set up.
>>
>> My 2c.
>>
>> Chris
>>
>> -----Original Message-----
>> From: Philip Laing [mailto:philip.laing@ascconsultants.com.au]
>> Sent: Tuesday, October 02, 2007 12:05 AM
>> To: user@ofbiz.apache.org
>> Subject: Linux distro?
>>
>> Thanks skip - just looking at a review on CentOS at the moment.  Looks
>> fairly impressive for server stability
>>
>> cheers
>>
>> Phil
>>
>>> -----Original Message-----
>>> From: skip@theDevers [mailto:skip@thedevers.org]
>>> Sent: Tuesday, 2 October 2007 1:59 PM
>>> To: user@ofbiz.apache.org
>>> Subject: RE: Download SVN Repository ... Linux distro?
>>>
>>> Instead of Fedora Core, give a look at CentOS.  Its a good deal more
>>> stable.
>>> I have had lots of weird problems with Fedora in the past (usually fixed
>>> within a few weeks, but still a pain when it happens).
>>>
>>> Skip
>>>
>>> -----Original Message-----
>>> From: Philip Laing [mailto:philip.laing@ascconsultants.com.au]
>>> Sent: Monday, October 01, 2007 6:01 PM
>>> To: user@ofbiz.apache.org
>>> Subject: RE: Download SVN Repository ... Linux distro?
>>>
>>>
>>> Thanks BJ ... Now what distro would be more suited these days?  I am
>>> looking
>>> at Fedora or Ununtu ... some may have preferences for viable reasons
>>>
>>> Thanks again ... quick reply to my question ... I think I am going to
> like
>>> setting up and configuring OFBiz
>>>
>>> Phil
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: BJ Freeman [mailto:bjfree@free-man.net]
>>>> Sent: Tuesday, 2 October 2007 10:29 AM
>>>> To: user@ofbiz.apache.org
>>>> Subject: Re: Download SVN Repository
>>>>
>>>> first read
>>>>
> http://docs.ofbiz.org/display/OFBTECH/Apache+OFBiz+Technical+Production+Se
>>>> tup+Guide\
>>>> http://docs.ofbiz.org/display/OFBIZ/How+to+run+OFBiz+as+a+Service
>>>> may help.
>>>> then on your linux box
>>>> load svn
>>>> some use wget
>>>> then you can use the svn commands to load ofbiz.
>>>> http://docs.ofbiz.org/display/OFBADMIN/Demo+and+Test+Setup+Guide
>>>>
>>>> Philip Laing sent the following on 10/1/2007 5:06 PM:
>>>>> Hi Fellas
>>>>> I am preparing a Linux box with OFBiz + PostgreSQL ... I have had
>>>> Compiere
>>>>> and OpenBravo installed on my windows server boxes and have
>>> investigated
>>>>> TinyERP however OFBiz seems to fit in better with my business model
>>>> which
>>>>> largely consists of virtual warehousing and drop ship ecommerce.  This
>>>> is my
>>>>> first posting in this forum so excuse me if I have missed any protocol
>>>> or my
>>>>> questions seem simplistic. So here we go
>>>>>
>>>>> 1. How do I download from the required SVN repositories using windows?
>>>>> 2. Search the list archives for threads other than scrolling through
>>> one
>>>> by
>>>>> one?
>>>>>
>>>>> Thanks in advance
>>>>> Wikitec
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>
>>
>>
>>
>>
> 
> 
> 
>

RE: Linux distro?

Posted by Skip <sk...@thedevers.org>.

BJ

Thats a good idea, I would be particularly happy to hear about 64 bit
gotchas.  I seem to remember hearing about memory > 2gigs causing a problem
with multiple CPUs and > 2gigs of memory or some such.

Skip

-----Original Message-----
From: BJ Freeman [mailto:bjfree@free-man.net]
Sent: Tuesday, October 02, 2007 9:30 AM
To: user@ofbiz.apache.org
Subject: Re: Linux distro?


The only condsideration is if the distro you your plan to use supports
Sun SDK package.
as long as you have 1.5 or better on you box then you ok.
Fedora installs the opensource SDK and yum does not work to get the sun SDK.

Maybe we should put a doc file up that everyone can put what distro they
have tried and if they were sucessful or not.



clearchris sent the following on 10/2/2007 8:41 AM:
> I plan on running Gentoo, though many disagree with that choice.
>
> http://linux.slashdot.org/linux/07/01/28/2227232.shtml
>
> I find that using the stable (non ~) branch with occasional upgrades to
~x86
> (unstable) programs runs quite well.  It's the best of both worlds IMHO,
you
> can get the stable software and you can get the newer fixes that you
> inevitably will need.  Best of all, it provides a nice framework for
> managing that complexity.
>
> If you plan on using the POS application under linux, I'd highly suggest
> using a 32 bit distribution, even if you have a 64 bit processor.  Most
> (nearly all it seems) JavaPOS drivers have a native binary component that
is
> 32 bit.  While AMD processors can run 32 bit code natively, the binary
> drivers require 32 bit system libraries, etc, which can get a bit
> interesting to set up.
>
> My 2c.
>
> Chris
>
> -----Original Message-----
> From: Philip Laing [mailto:philip.laing@ascconsultants.com.au]
> Sent: Tuesday, October 02, 2007 12:05 AM
> To: user@ofbiz.apache.org
> Subject: Linux distro?
>
> Thanks skip - just looking at a review on CentOS at the moment.  Looks
> fairly impressive for server stability
>
> cheers
>
> Phil
>
>> -----Original Message-----
>> From: skip@theDevers [mailto:skip@thedevers.org]
>> Sent: Tuesday, 2 October 2007 1:59 PM
>> To: user@ofbiz.apache.org
>> Subject: RE: Download SVN Repository ... Linux distro?
>>
>> Instead of Fedora Core, give a look at CentOS.  Its a good deal more
>> stable.
>> I have had lots of weird problems with Fedora in the past (usually fixed
>> within a few weeks, but still a pain when it happens).
>>
>> Skip
>>
>> -----Original Message-----
>> From: Philip Laing [mailto:philip.laing@ascconsultants.com.au]
>> Sent: Monday, October 01, 2007 6:01 PM
>> To: user@ofbiz.apache.org
>> Subject: RE: Download SVN Repository ... Linux distro?
>>
>>
>> Thanks BJ ... Now what distro would be more suited these days?  I am
>> looking
>> at Fedora or Ununtu ... some may have preferences for viable reasons
>>
>> Thanks again ... quick reply to my question ... I think I am going to
like
>> setting up and configuring OFBiz
>>
>> Phil
>>
>>
>>
>>> -----Original Message-----
>>> From: BJ Freeman [mailto:bjfree@free-man.net]
>>> Sent: Tuesday, 2 October 2007 10:29 AM
>>> To: user@ofbiz.apache.org
>>> Subject: Re: Download SVN Repository
>>>
>>> first read
>>>
>>
http://docs.ofbiz.org/display/OFBTECH/Apache+OFBiz+Technical+Production+Se
>>> tup+Guide\
>>> http://docs.ofbiz.org/display/OFBIZ/How+to+run+OFBiz+as+a+Service
>>> may help.
>>> then on your linux box
>>> load svn
>>> some use wget
>>> then you can use the svn commands to load ofbiz.
>>> http://docs.ofbiz.org/display/OFBADMIN/Demo+and+Test+Setup+Guide
>>>
>>> Philip Laing sent the following on 10/1/2007 5:06 PM:
>>>> Hi Fellas
>>>> I am preparing a Linux box with OFBiz + PostgreSQL ... I have had
>>> Compiere
>>>> and OpenBravo installed on my windows server boxes and have
>> investigated
>>>> TinyERP however OFBiz seems to fit in better with my business model
>>> which
>>>> largely consists of virtual warehousing and drop ship ecommerce.  This
>>> is my
>>>> first posting in this forum so excuse me if I have missed any protocol
>>> or my
>>>> questions seem simplistic. So here we go
>>>>
>>>> 1. How do I download from the required SVN repositories using windows?
>>>> 2. Search the list archives for threads other than scrolling through
>> one
>>> by
>>>> one?
>>>>
>>>> Thanks in advance
>>>> Wikitec
>>>>
>>>>
>>>>
>>>>
>>>>
>
>
>
>
>
>

Re: Linux distro?

Posted by BJ Freeman <bj...@free-man.net>.

The only condsideration is if the distro you your plan to use supports
Sun SDK package.
as long as you have 1.5 or better on you box then you ok.
Fedora installs the opensource SDK and yum does not work to get the sun SDK.

Maybe we should put a doc file up that everyone can put what distro they
have tried and if they were sucessful or not.



clearchris sent the following on 10/2/2007 8:41 AM:
> I plan on running Gentoo, though many disagree with that choice.
> 
> http://linux.slashdot.org/linux/07/01/28/2227232.shtml
> 
> I find that using the stable (non ~) branch with occasional upgrades to ~x86
> (unstable) programs runs quite well.  It's the best of both worlds IMHO, you
> can get the stable software and you can get the newer fixes that you
> inevitably will need.  Best of all, it provides a nice framework for
> managing that complexity.
> 
> If you plan on using the POS application under linux, I'd highly suggest
> using a 32 bit distribution, even if you have a 64 bit processor.  Most
> (nearly all it seems) JavaPOS drivers have a native binary component that is
> 32 bit.  While AMD processors can run 32 bit code natively, the binary
> drivers require 32 bit system libraries, etc, which can get a bit
> interesting to set up.
> 
> My 2c.
> 
> Chris
> 
> -----Original Message-----
> From: Philip Laing [mailto:philip.laing@ascconsultants.com.au] 
> Sent: Tuesday, October 02, 2007 12:05 AM
> To: user@ofbiz.apache.org
> Subject: Linux distro?
> 
> Thanks skip - just looking at a review on CentOS at the moment.  Looks
> fairly impressive for server stability
> 
> cheers
> 
> Phil
> 
>> -----Original Message-----
>> From: skip@theDevers [mailto:skip@thedevers.org]
>> Sent: Tuesday, 2 October 2007 1:59 PM
>> To: user@ofbiz.apache.org
>> Subject: RE: Download SVN Repository ... Linux distro?
>>
>> Instead of Fedora Core, give a look at CentOS.  Its a good deal more
>> stable.
>> I have had lots of weird problems with Fedora in the past (usually fixed
>> within a few weeks, but still a pain when it happens).
>>
>> Skip
>>
>> -----Original Message-----
>> From: Philip Laing [mailto:philip.laing@ascconsultants.com.au]
>> Sent: Monday, October 01, 2007 6:01 PM
>> To: user@ofbiz.apache.org
>> Subject: RE: Download SVN Repository ... Linux distro?
>>
>>
>> Thanks BJ ... Now what distro would be more suited these days?  I am
>> looking
>> at Fedora or Ununtu ... some may have preferences for viable reasons
>>
>> Thanks again ... quick reply to my question ... I think I am going to like
>> setting up and configuring OFBiz
>>
>> Phil
>>
>>
>>
>>> -----Original Message-----
>>> From: BJ Freeman [mailto:bjfree@free-man.net]
>>> Sent: Tuesday, 2 October 2007 10:29 AM
>>> To: user@ofbiz.apache.org
>>> Subject: Re: Download SVN Repository
>>>
>>> first read
>>>
>> http://docs.ofbiz.org/display/OFBTECH/Apache+OFBiz+Technical+Production+Se
>>> tup+Guide\
>>> http://docs.ofbiz.org/display/OFBIZ/How+to+run+OFBiz+as+a+Service
>>> may help.
>>> then on your linux box
>>> load svn
>>> some use wget
>>> then you can use the svn commands to load ofbiz.
>>> http://docs.ofbiz.org/display/OFBADMIN/Demo+and+Test+Setup+Guide
>>>
>>> Philip Laing sent the following on 10/1/2007 5:06 PM:
>>>> Hi Fellas
>>>> I am preparing a Linux box with OFBiz + PostgreSQL ... I have had
>>> Compiere
>>>> and OpenBravo installed on my windows server boxes and have
>> investigated
>>>> TinyERP however OFBiz seems to fit in better with my business model
>>> which
>>>> largely consists of virtual warehousing and drop ship ecommerce.  This
>>> is my
>>>> first posting in this forum so excuse me if I have missed any protocol
>>> or my
>>>> questions seem simplistic. So here we go
>>>>
>>>> 1. How do I download from the required SVN repositories using windows?
>>>> 2. Search the list archives for threads other than scrolling through
>> one
>>> by
>>>> one?
>>>>
>>>> Thanks in advance
>>>> Wikitec
>>>>
>>>>
>>>>
>>>>
>>>>
> 
> 
> 
> 
> 
>

Linux specific bugs [was Re: Linux distro?]

Posted by Jacques Le Roux <ja...@les7arts.com>.

Yes, why not ? Though I'm not aware of any other Linux specific bugs

Jacques

De : "BJ Freeman" <bj...@free-man.net>
> so should there be a Linux bugs in our JIRA
> then link this one to it so others can be linked as well?
> 
> Jacques Le Roux sent the following on 10/2/2007 12:02 PM:
> > POS : remember that AFAIK this issue still exists on Linux https://issues.apache.org/jira/browse/OFBIZ-567
> > 
> > Jacques
> > 
> > De : "clearchris" <cl...@hotmail.com>
> >> I plan on running Gentoo, though many disagree with that choice.
> >>
> >> http://linux.slashdot.org/linux/07/01/28/2227232.shtml
> >>
> >> I find that using the stable (non ~) branch with occasional upgrades to ~x86
> >> (unstable) programs runs quite well.  It's the best of both worlds IMHO, you
> >> can get the stable software and you can get the newer fixes that you
> >> inevitably will need.  Best of all, it provides a nice framework for
> >> managing that complexity.
> >>
> >> If you plan on using the POS application under linux, I'd highly suggest
> >> using a 32 bit distribution, even if you have a 64 bit processor.  Most
> >> (nearly all it seems) JavaPOS drivers have a native binary component that is
> >> 32 bit.  While AMD processors can run 32 bit code natively, the binary
> >> drivers require 32 bit system libraries, etc, which can get a bit
> >> interesting to set up.
> >>
> >> My 2c.
> >>
> >> Chris
> >>
> >> -----Original Message-----
> >> From: Philip Laing [mailto:philip.laing@ascconsultants.com.au] 
> >> Sent: Tuesday, October 02, 2007 12:05 AM
> >> To: user@ofbiz.apache.org
> >> Subject: Linux distro?
> >>
> >> Thanks skip - just looking at a review on CentOS at the moment.  Looks
> >> fairly impressive for server stability
> >>
> >> cheers
> >>
> >> Phil
> >>
> >>> -----Original Message-----
> >>> From: skip@theDevers [mailto:skip@thedevers.org]
> >>> Sent: Tuesday, 2 October 2007 1:59 PM
> >>> To: user@ofbiz.apache.org
> >>> Subject: RE: Download SVN Repository ... Linux distro?
> >>>
> >>> Instead of Fedora Core, give a look at CentOS.  Its a good deal more
> >>> stable.
> >>> I have had lots of weird problems with Fedora in the past (usually fixed
> >>> within a few weeks, but still a pain when it happens).
> >>>
> >>> Skip
> >>>
> >>> -----Original Message-----
> >>> From: Philip Laing [mailto:philip.laing@ascconsultants.com.au]
> >>> Sent: Monday, October 01, 2007 6:01 PM
> >>> To: user@ofbiz.apache.org
> >>> Subject: RE: Download SVN Repository ... Linux distro?
> >>>
> >>>
> >>> Thanks BJ ... Now what distro would be more suited these days?  I am
> >>> looking
> >>> at Fedora or Ununtu ... some may have preferences for viable reasons
> >>>
> >>> Thanks again ... quick reply to my question ... I think I am going to like
> >>> setting up and configuring OFBiz
> >>>
> >>> Phil
> >>>
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: BJ Freeman [mailto:bjfree@free-man.net]
> >>>> Sent: Tuesday, 2 October 2007 10:29 AM
> >>>> To: user@ofbiz.apache.org
> >>>> Subject: Re: Download SVN Repository
> >>>>
> >>>> first read
> >>>>
> >>> http://docs.ofbiz.org/display/OFBTECH/Apache+OFBiz+Technical+Production+Se
> >>>> tup+Guide\
> >>>> http://docs.ofbiz.org/display/OFBIZ/How+to+run+OFBiz+as+a+Service
> >>>> may help.
> >>>> then on your linux box
> >>>> load svn
> >>>> some use wget
> >>>> then you can use the svn commands to load ofbiz.
> >>>> http://docs.ofbiz.org/display/OFBADMIN/Demo+and+Test+Setup+Guide
> >>>>
> >>>> Philip Laing sent the following on 10/1/2007 5:06 PM:
> >>>>> Hi Fellas
> >>>>> I am preparing a Linux box with OFBiz + PostgreSQL ... I have had
> >>>> Compiere
> >>>>> and OpenBravo installed on my windows server boxes and have
> >>> investigated
> >>>>> TinyERP however OFBiz seems to fit in better with my business model
> >>>> which
> >>>>> largely consists of virtual warehousing and drop ship ecommerce.  This
> >>>> is my
> >>>>> first posting in this forum so excuse me if I have missed any protocol
> >>>> or my
> >>>>> questions seem simplistic. So here we go
> >>>>>
> >>>>> 1. How do I download from the required SVN repositories using windows?
> >>>>> 2. Search the list archives for threads other than scrolling through
> >>> one
> >>>> by
> >>>>> one?
> >>>>>
> >>>>> Thanks in advance
> >>>>> Wikitec
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>
> >>
> > 
> > 
> > 
>

Re: Linux distro?

Posted by BJ Freeman <bj...@free-man.net>.

so should there be a Linux bugs in our JIRA
then link this one to it so others can be linked as well?

Jacques Le Roux sent the following on 10/2/2007 12:02 PM:
> POS : remember that AFAIK this issue still exists on Linux https://issues.apache.org/jira/browse/OFBIZ-567
> 
> Jacques
> 
> De : "clearchris" <cl...@hotmail.com>
>> I plan on running Gentoo, though many disagree with that choice.
>>
>> http://linux.slashdot.org/linux/07/01/28/2227232.shtml
>>
>> I find that using the stable (non ~) branch with occasional upgrades to ~x86
>> (unstable) programs runs quite well.  It's the best of both worlds IMHO, you
>> can get the stable software and you can get the newer fixes that you
>> inevitably will need.  Best of all, it provides a nice framework for
>> managing that complexity.
>>
>> If you plan on using the POS application under linux, I'd highly suggest
>> using a 32 bit distribution, even if you have a 64 bit processor.  Most
>> (nearly all it seems) JavaPOS drivers have a native binary component that is
>> 32 bit.  While AMD processors can run 32 bit code natively, the binary
>> drivers require 32 bit system libraries, etc, which can get a bit
>> interesting to set up.
>>
>> My 2c.
>>
>> Chris
>>
>> -----Original Message-----
>> From: Philip Laing [mailto:philip.laing@ascconsultants.com.au] 
>> Sent: Tuesday, October 02, 2007 12:05 AM
>> To: user@ofbiz.apache.org
>> Subject: Linux distro?
>>
>> Thanks skip - just looking at a review on CentOS at the moment.  Looks
>> fairly impressive for server stability
>>
>> cheers
>>
>> Phil
>>
>>> -----Original Message-----
>>> From: skip@theDevers [mailto:skip@thedevers.org]
>>> Sent: Tuesday, 2 October 2007 1:59 PM
>>> To: user@ofbiz.apache.org
>>> Subject: RE: Download SVN Repository ... Linux distro?
>>>
>>> Instead of Fedora Core, give a look at CentOS.  Its a good deal more
>>> stable.
>>> I have had lots of weird problems with Fedora in the past (usually fixed
>>> within a few weeks, but still a pain when it happens).
>>>
>>> Skip
>>>
>>> -----Original Message-----
>>> From: Philip Laing [mailto:philip.laing@ascconsultants.com.au]
>>> Sent: Monday, October 01, 2007 6:01 PM
>>> To: user@ofbiz.apache.org
>>> Subject: RE: Download SVN Repository ... Linux distro?
>>>
>>>
>>> Thanks BJ ... Now what distro would be more suited these days?  I am
>>> looking
>>> at Fedora or Ununtu ... some may have preferences for viable reasons
>>>
>>> Thanks again ... quick reply to my question ... I think I am going to like
>>> setting up and configuring OFBiz
>>>
>>> Phil
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: BJ Freeman [mailto:bjfree@free-man.net]
>>>> Sent: Tuesday, 2 October 2007 10:29 AM
>>>> To: user@ofbiz.apache.org
>>>> Subject: Re: Download SVN Repository
>>>>
>>>> first read
>>>>
>>> http://docs.ofbiz.org/display/OFBTECH/Apache+OFBiz+Technical+Production+Se
>>>> tup+Guide\
>>>> http://docs.ofbiz.org/display/OFBIZ/How+to+run+OFBiz+as+a+Service
>>>> may help.
>>>> then on your linux box
>>>> load svn
>>>> some use wget
>>>> then you can use the svn commands to load ofbiz.
>>>> http://docs.ofbiz.org/display/OFBADMIN/Demo+and+Test+Setup+Guide
>>>>
>>>> Philip Laing sent the following on 10/1/2007 5:06 PM:
>>>>> Hi Fellas
>>>>> I am preparing a Linux box with OFBiz + PostgreSQL ... I have had
>>>> Compiere
>>>>> and OpenBravo installed on my windows server boxes and have
>>> investigated
>>>>> TinyERP however OFBiz seems to fit in better with my business model
>>>> which
>>>>> largely consists of virtual warehousing and drop ship ecommerce.  This
>>>> is my
>>>>> first posting in this forum so excuse me if I have missed any protocol
>>>> or my
>>>>> questions seem simplistic. So here we go
>>>>>
>>>>> 1. How do I download from the required SVN repositories using windows?
>>>>> 2. Search the list archives for threads other than scrolling through
>>> one
>>>> by
>>>>> one?
>>>>>
>>>>> Thanks in advance
>>>>> Wikitec
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>
>>
> 
> 
>

Re: Linux distro?

Posted by Jacques Le Roux <ja...@les7arts.com>.

Chris,

I posted this message in https://issues.apache.org/jira/browse/OFBIZ-567 (Problem with POS modal window on Linux)

Could you please explain or provide a patch for your solution with the double keyboard issue ?

Thanks

Jacques

De : "clearchris" <cl...@hotmail.com>


> The "UseWindow=false" setting seems to make the POS work as I would expect
> the POS to work (i.e. no title bar and it runs un-windowed).  The only
> difference is that there's the issue of being able to alt-tab to other
> screens, but I think that's more an OS security issue and less a POS
> application issue.
> 
> It would probably be good to have links to documentation on how to harden an
> X session or protect the passwords to the database, etc.  Unfortunately, I
> don't have much to offer on that issue as I haven't looked into it yet.  It
> has definitely been on my mind though.
> 
> On a related note, I think I may know what is causing the double keyboard
> events in linux mentioned in the ticket.  I was seeing a similar problem
> with mouse clicks and changing the event handler worked.
> 
> Chris
> 
> -----Original Message-----
> From: Jacques Le Roux [mailto:jacques.le.roux@les7arts.com] 
> Sent: Tuesday, October 02, 2007 2:03 PM
> To: user@ofbiz.apache.org
> Subject: Re: Linux distro?
> 
> POS : remember that AFAIK this issue still exists on Linux
> https://issues.apache.org/jira/browse/OFBIZ-567
> 
> Jacques
> 
> De : "clearchris" <cl...@hotmail.com>
> > I plan on running Gentoo, though many disagree with that choice.
> > 
> > http://linux.slashdot.org/linux/07/01/28/2227232.shtml
> > 
> > I find that using the stable (non ~) branch with occasional upgrades to
> ~x86
> > (unstable) programs runs quite well.  It's the best of both worlds IMHO,
> you
> > can get the stable software and you can get the newer fixes that you
> > inevitably will need.  Best of all, it provides a nice framework for
> > managing that complexity.
> > 
> > If you plan on using the POS application under linux, I'd highly suggest
> > using a 32 bit distribution, even if you have a 64 bit processor.  Most
> > (nearly all it seems) JavaPOS drivers have a native binary component that
> is
> > 32 bit.  While AMD processors can run 32 bit code natively, the binary
> > drivers require 32 bit system libraries, etc, which can get a bit
> > interesting to set up.
> > 
> > My 2c.
> > 
> > Chris
> > 
> > -----Original Message-----
> > From: Philip Laing [mailto:philip.laing@ascconsultants.com.au] 
> > Sent: Tuesday, October 02, 2007 12:05 AM
> > To: user@ofbiz.apache.org
> > Subject: Linux distro?
> > 
> > Thanks skip - just looking at a review on CentOS at the moment.  Looks
> > fairly impressive for server stability
> > 
> > cheers
> > 
> > Phil
> > 
> > > -----Original Message-----
> > > From: skip@theDevers [mailto:skip@thedevers.org]
> > > Sent: Tuesday, 2 October 2007 1:59 PM
> > > To: user@ofbiz.apache.org
> > > Subject: RE: Download SVN Repository ... Linux distro?
> > > 
> > > Instead of Fedora Core, give a look at CentOS.  Its a good deal more
> > > stable.
> > > I have had lots of weird problems with Fedora in the past (usually fixed
> > > within a few weeks, but still a pain when it happens).
> > > 
> > > Skip
> > > 
> > > -----Original Message-----
> > > From: Philip Laing [mailto:philip.laing@ascconsultants.com.au]
> > > Sent: Monday, October 01, 2007 6:01 PM
> > > To: user@ofbiz.apache.org
> > > Subject: RE: Download SVN Repository ... Linux distro?
> > > 
> > > 
> > > Thanks BJ ... Now what distro would be more suited these days?  I am
> > > looking
> > > at Fedora or Ununtu ... some may have preferences for viable reasons
> > > 
> > > Thanks again ... quick reply to my question ... I think I am going to
> like
> > > setting up and configuring OFBiz
> > > 
> > > Phil
> > > 
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: BJ Freeman [mailto:bjfree@free-man.net]
> > > > Sent: Tuesday, 2 October 2007 10:29 AM
> > > > To: user@ofbiz.apache.org
> > > > Subject: Re: Download SVN Repository
> > > >
> > > > first read
> > > >
> > >
> http://docs.ofbiz.org/display/OFBTECH/Apache+OFBiz+Technical+Production+Se
> > > > tup+Guide\
> > > > http://docs.ofbiz.org/display/OFBIZ/How+to+run+OFBiz+as+a+Service
> > > > may help.
> > > > then on your linux box
> > > > load svn
> > > > some use wget
> > > > then you can use the svn commands to load ofbiz.
> > > > http://docs.ofbiz.org/display/OFBADMIN/Demo+and+Test+Setup+Guide
> > > >
> > > > Philip Laing sent the following on 10/1/2007 5:06 PM:
> > > > > Hi Fellas
> > > > > I am preparing a Linux box with OFBiz + PostgreSQL ... I have had
> > > > Compiere
> > > > > and OpenBravo installed on my windows server boxes and have
> > > investigated
> > > > > TinyERP however OFBiz seems to fit in better with my business model
> > > > which
> > > > > largely consists of virtual warehousing and drop ship ecommerce.
> This
> > > > is my
> > > > > first posting in this forum so excuse me if I have missed any
> protocol
> > > > or my
> > > > > questions seem simplistic. So here we go
> > > > >
> > > > > 1. How do I download from the required SVN repositories using
> windows?
> > > > > 2. Search the list archives for threads other than scrolling through
> > > one
> > > > by
> > > > > one?
> > > > >
> > > > > Thanks in advance
> > > > > Wikitec
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > 
> > 
> > 
>

RE: Linux distro?

Posted by clearchris <cl...@hotmail.com>.

The "UseWindow=false" setting seems to make the POS work as I would expect
the POS to work (i.e. no title bar and it runs un-windowed).  The only
difference is that there's the issue of being able to alt-tab to other
screens, but I think that's more an OS security issue and less a POS
application issue.

It would probably be good to have links to documentation on how to harden an
X session or protect the passwords to the database, etc.  Unfortunately, I
don't have much to offer on that issue as I haven't looked into it yet.  It
has definitely been on my mind though.

On a related note, I think I may know what is causing the double keyboard
events in linux mentioned in the ticket.  I was seeing a similar problem
with mouse clicks and changing the event handler worked.

Chris

-----Original Message-----
From: Jacques Le Roux [mailto:jacques.le.roux@les7arts.com] 
Sent: Tuesday, October 02, 2007 2:03 PM
To: user@ofbiz.apache.org
Subject: Re: Linux distro?

POS : remember that AFAIK this issue still exists on Linux
https://issues.apache.org/jira/browse/OFBIZ-567

Jacques

De : "clearchris" <cl...@hotmail.com>
> I plan on running Gentoo, though many disagree with that choice.
> 
> http://linux.slashdot.org/linux/07/01/28/2227232.shtml
> 
> I find that using the stable (non ~) branch with occasional upgrades to
~x86
> (unstable) programs runs quite well.  It's the best of both worlds IMHO,
you
> can get the stable software and you can get the newer fixes that you
> inevitably will need.  Best of all, it provides a nice framework for
> managing that complexity.
> 
> If you plan on using the POS application under linux, I'd highly suggest
> using a 32 bit distribution, even if you have a 64 bit processor.  Most
> (nearly all it seems) JavaPOS drivers have a native binary component that
is
> 32 bit.  While AMD processors can run 32 bit code natively, the binary
> drivers require 32 bit system libraries, etc, which can get a bit
> interesting to set up.
> 
> My 2c.
> 
> Chris
> 
> -----Original Message-----
> From: Philip Laing [mailto:philip.laing@ascconsultants.com.au] 
> Sent: Tuesday, October 02, 2007 12:05 AM
> To: user@ofbiz.apache.org
> Subject: Linux distro?
> 
> Thanks skip - just looking at a review on CentOS at the moment.  Looks
> fairly impressive for server stability
> 
> cheers
> 
> Phil
> 
> > -----Original Message-----
> > From: skip@theDevers [mailto:skip@thedevers.org]
> > Sent: Tuesday, 2 October 2007 1:59 PM
> > To: user@ofbiz.apache.org
> > Subject: RE: Download SVN Repository ... Linux distro?
> > 
> > Instead of Fedora Core, give a look at CentOS.  Its a good deal more
> > stable.
> > I have had lots of weird problems with Fedora in the past (usually fixed
> > within a few weeks, but still a pain when it happens).
> > 
> > Skip
> > 
> > -----Original Message-----
> > From: Philip Laing [mailto:philip.laing@ascconsultants.com.au]
> > Sent: Monday, October 01, 2007 6:01 PM
> > To: user@ofbiz.apache.org
> > Subject: RE: Download SVN Repository ... Linux distro?
> > 
> > 
> > Thanks BJ ... Now what distro would be more suited these days?  I am
> > looking
> > at Fedora or Ununtu ... some may have preferences for viable reasons
> > 
> > Thanks again ... quick reply to my question ... I think I am going to
like
> > setting up and configuring OFBiz
> > 
> > Phil
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: BJ Freeman [mailto:bjfree@free-man.net]
> > > Sent: Tuesday, 2 October 2007 10:29 AM
> > > To: user@ofbiz.apache.org
> > > Subject: Re: Download SVN Repository
> > >
> > > first read
> > >
> >
http://docs.ofbiz.org/display/OFBTECH/Apache+OFBiz+Technical+Production+Se
> > > tup+Guide\
> > > http://docs.ofbiz.org/display/OFBIZ/How+to+run+OFBiz+as+a+Service
> > > may help.
> > > then on your linux box
> > > load svn
> > > some use wget
> > > then you can use the svn commands to load ofbiz.
> > > http://docs.ofbiz.org/display/OFBADMIN/Demo+and+Test+Setup+Guide
> > >
> > > Philip Laing sent the following on 10/1/2007 5:06 PM:
> > > > Hi Fellas
> > > > I am preparing a Linux box with OFBiz + PostgreSQL ... I have had
> > > Compiere
> > > > and OpenBravo installed on my windows server boxes and have
> > investigated
> > > > TinyERP however OFBiz seems to fit in better with my business model
> > > which
> > > > largely consists of virtual warehousing and drop ship ecommerce.
This
> > > is my
> > > > first posting in this forum so excuse me if I have missed any
protocol
> > > or my
> > > > questions seem simplistic. So here we go
> > > >
> > > > 1. How do I download from the required SVN repositories using
windows?
> > > > 2. Search the list archives for threads other than scrolling through
> > one
> > > by
> > > > one?
> > > >
> > > > Thanks in advance
> > > > Wikitec
> > > >
> > > >
> > > >
> > > >
> > > >
> 
> 
>

Re: Linux distro?

Posted by Jacques Le Roux <ja...@les7arts.com>.

POS : remember that AFAIK this issue still exists on Linux https://issues.apache.org/jira/browse/OFBIZ-567

Jacques

De : "clearchris" <cl...@hotmail.com>
> I plan on running Gentoo, though many disagree with that choice.
> 
> http://linux.slashdot.org/linux/07/01/28/2227232.shtml
> 
> I find that using the stable (non ~) branch with occasional upgrades to ~x86
> (unstable) programs runs quite well.  It's the best of both worlds IMHO, you
> can get the stable software and you can get the newer fixes that you
> inevitably will need.  Best of all, it provides a nice framework for
> managing that complexity.
> 
> If you plan on using the POS application under linux, I'd highly suggest
> using a 32 bit distribution, even if you have a 64 bit processor.  Most
> (nearly all it seems) JavaPOS drivers have a native binary component that is
> 32 bit.  While AMD processors can run 32 bit code natively, the binary
> drivers require 32 bit system libraries, etc, which can get a bit
> interesting to set up.
> 
> My 2c.
> 
> Chris
> 
> -----Original Message-----
> From: Philip Laing [mailto:philip.laing@ascconsultants.com.au] 
> Sent: Tuesday, October 02, 2007 12:05 AM
> To: user@ofbiz.apache.org
> Subject: Linux distro?
> 
> Thanks skip - just looking at a review on CentOS at the moment.  Looks
> fairly impressive for server stability
> 
> cheers
> 
> Phil
> 
> > -----Original Message-----
> > From: skip@theDevers [mailto:skip@thedevers.org]
> > Sent: Tuesday, 2 October 2007 1:59 PM
> > To: user@ofbiz.apache.org
> > Subject: RE: Download SVN Repository ... Linux distro?
> > 
> > Instead of Fedora Core, give a look at CentOS.  Its a good deal more
> > stable.
> > I have had lots of weird problems with Fedora in the past (usually fixed
> > within a few weeks, but still a pain when it happens).
> > 
> > Skip
> > 
> > -----Original Message-----
> > From: Philip Laing [mailto:philip.laing@ascconsultants.com.au]
> > Sent: Monday, October 01, 2007 6:01 PM
> > To: user@ofbiz.apache.org
> > Subject: RE: Download SVN Repository ... Linux distro?
> > 
> > 
> > Thanks BJ ... Now what distro would be more suited these days?  I am
> > looking
> > at Fedora or Ununtu ... some may have preferences for viable reasons
> > 
> > Thanks again ... quick reply to my question ... I think I am going to like
> > setting up and configuring OFBiz
> > 
> > Phil
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: BJ Freeman [mailto:bjfree@free-man.net]
> > > Sent: Tuesday, 2 October 2007 10:29 AM
> > > To: user@ofbiz.apache.org
> > > Subject: Re: Download SVN Repository
> > >
> > > first read
> > >
> > http://docs.ofbiz.org/display/OFBTECH/Apache+OFBiz+Technical+Production+Se
> > > tup+Guide\
> > > http://docs.ofbiz.org/display/OFBIZ/How+to+run+OFBiz+as+a+Service
> > > may help.
> > > then on your linux box
> > > load svn
> > > some use wget
> > > then you can use the svn commands to load ofbiz.
> > > http://docs.ofbiz.org/display/OFBADMIN/Demo+and+Test+Setup+Guide
> > >
> > > Philip Laing sent the following on 10/1/2007 5:06 PM:
> > > > Hi Fellas
> > > > I am preparing a Linux box with OFBiz + PostgreSQL ... I have had
> > > Compiere
> > > > and OpenBravo installed on my windows server boxes and have
> > investigated
> > > > TinyERP however OFBiz seems to fit in better with my business model
> > > which
> > > > largely consists of virtual warehousing and drop ship ecommerce.  This
> > > is my
> > > > first posting in this forum so excuse me if I have missed any protocol
> > > or my
> > > > questions seem simplistic. So here we go
> > > >
> > > > 1. How do I download from the required SVN repositories using windows?
> > > > 2. Search the list archives for threads other than scrolling through
> > one
> > > by
> > > > one?
> > > >
> > > > Thanks in advance
> > > > Wikitec
> > > >
> > > >
> > > >
> > > >
> > > >
> 
> 
>

RE: Linux distro?

Posted by clearchris <cl...@hotmail.com>.

I plan on running Gentoo, though many disagree with that choice.

http://linux.slashdot.org/linux/07/01/28/2227232.shtml

I find that using the stable (non ~) branch with occasional upgrades to ~x86
(unstable) programs runs quite well.  It's the best of both worlds IMHO, you
can get the stable software and you can get the newer fixes that you
inevitably will need.  Best of all, it provides a nice framework for
managing that complexity.

If you plan on using the POS application under linux, I'd highly suggest
using a 32 bit distribution, even if you have a 64 bit processor.  Most
(nearly all it seems) JavaPOS drivers have a native binary component that is
32 bit.  While AMD processors can run 32 bit code natively, the binary
drivers require 32 bit system libraries, etc, which can get a bit
interesting to set up.

My 2c.

Chris

-----Original Message-----
From: Philip Laing [mailto:philip.laing@ascconsultants.com.au] 
Sent: Tuesday, October 02, 2007 12:05 AM
To: user@ofbiz.apache.org
Subject: Linux distro?

Thanks skip - just looking at a review on CentOS at the moment.  Looks
fairly impressive for server stability

cheers

Phil

> -----Original Message-----
> From: skip@theDevers [mailto:skip@thedevers.org]
> Sent: Tuesday, 2 October 2007 1:59 PM
> To: user@ofbiz.apache.org
> Subject: RE: Download SVN Repository ... Linux distro?
> 
> Instead of Fedora Core, give a look at CentOS.  Its a good deal more
> stable.
> I have had lots of weird problems with Fedora in the past (usually fixed
> within a few weeks, but still a pain when it happens).
> 
> Skip
> 
> -----Original Message-----
> From: Philip Laing [mailto:philip.laing@ascconsultants.com.au]
> Sent: Monday, October 01, 2007 6:01 PM
> To: user@ofbiz.apache.org
> Subject: RE: Download SVN Repository ... Linux distro?
> 
> 
> Thanks BJ ... Now what distro would be more suited these days?  I am
> looking
> at Fedora or Ununtu ... some may have preferences for viable reasons
> 
> Thanks again ... quick reply to my question ... I think I am going to like
> setting up and configuring OFBiz
> 
> Phil
> 
> 
> 
> > -----Original Message-----
> > From: BJ Freeman [mailto:bjfree@free-man.net]
> > Sent: Tuesday, 2 October 2007 10:29 AM
> > To: user@ofbiz.apache.org
> > Subject: Re: Download SVN Repository
> >
> > first read
> >
> http://docs.ofbiz.org/display/OFBTECH/Apache+OFBiz+Technical+Production+Se
> > tup+Guide\
> > http://docs.ofbiz.org/display/OFBIZ/How+to+run+OFBiz+as+a+Service
> > may help.
> > then on your linux box
> > load svn
> > some use wget
> > then you can use the svn commands to load ofbiz.
> > http://docs.ofbiz.org/display/OFBADMIN/Demo+and+Test+Setup+Guide
> >
> > Philip Laing sent the following on 10/1/2007 5:06 PM:
> > > Hi Fellas
> > > I am preparing a Linux box with OFBiz + PostgreSQL ... I have had
> > Compiere
> > > and OpenBravo installed on my windows server boxes and have
> investigated
> > > TinyERP however OFBiz seems to fit in better with my business model
> > which
> > > largely consists of virtual warehousing and drop ship ecommerce.  This
> > is my
> > > first posting in this forum so excuse me if I have missed any protocol
> > or my
> > > questions seem simplistic. So here we go
> > >
> > > 1. How do I download from the required SVN repositories using windows?
> > > 2. Search the list archives for threads other than scrolling through
> one
> > by
> > > one?
> > >
> > > Thanks in advance
> > > Wikitec
> > >
> > >
> > >
> > >
> > >

Linux distro?

Posted by Philip Laing <ph...@ascconsultants.com.au>.

Thanks skip - just looking at a review on CentOS at the moment.  Looks
fairly impressive for server stability

cheers

Phil

> -----Original Message-----
> From: skip@theDevers [mailto:skip@thedevers.org]
> Sent: Tuesday, 2 October 2007 1:59 PM
> To: user@ofbiz.apache.org
> Subject: RE: Download SVN Repository ... Linux distro?
> 
> Instead of Fedora Core, give a look at CentOS.  Its a good deal more
> stable.
> I have had lots of weird problems with Fedora in the past (usually fixed
> within a few weeks, but still a pain when it happens).
> 
> Skip
> 
> -----Original Message-----
> From: Philip Laing [mailto:philip.laing@ascconsultants.com.au]
> Sent: Monday, October 01, 2007 6:01 PM
> To: user@ofbiz.apache.org
> Subject: RE: Download SVN Repository ... Linux distro?
> 
> 
> Thanks BJ ... Now what distro would be more suited these days?  I am
> looking
> at Fedora or Ununtu ... some may have preferences for viable reasons
> 
> Thanks again ... quick reply to my question ... I think I am going to like
> setting up and configuring OFBiz
> 
> Phil
> 
> 
> 
> > -----Original Message-----
> > From: BJ Freeman [mailto:bjfree@free-man.net]
> > Sent: Tuesday, 2 October 2007 10:29 AM
> > To: user@ofbiz.apache.org
> > Subject: Re: Download SVN Repository
> >
> > first read
> >
> http://docs.ofbiz.org/display/OFBTECH/Apache+OFBiz+Technical+Production+Se
> > tup+Guide\
> > http://docs.ofbiz.org/display/OFBIZ/How+to+run+OFBiz+as+a+Service
> > may help.
> > then on your linux box
> > load svn
> > some use wget
> > then you can use the svn commands to load ofbiz.
> > http://docs.ofbiz.org/display/OFBADMIN/Demo+and+Test+Setup+Guide
> >
> > Philip Laing sent the following on 10/1/2007 5:06 PM:
> > > Hi Fellas
> > > I am preparing a Linux box with OFBiz + PostgreSQL ... I have had
> > Compiere
> > > and OpenBravo installed on my windows server boxes and have
> investigated
> > > TinyERP however OFBiz seems to fit in better with my business model
> > which
> > > largely consists of virtual warehousing and drop ship ecommerce.  This
> > is my
> > > first posting in this forum so excuse me if I have missed any protocol
> > or my
> > > questions seem simplistic. So here we go
> > >
> > > 1. How do I download from the required SVN repositories using windows?
> > > 2. Search the list archives for threads other than scrolling through
> one
> > by
> > > one?
> > >
> > > Thanks in advance
> > > Wikitec
> > >
> > >
> > >
> > >
> > >

Re: Download SVN Repository ... Linux distro?

Posted by Jonathon -- Improov <jo...@improov.com>.

A Linux distro that works perfectly with the JDK/JRE needed. The JDK/JRE used now is 1.5.

Beyond that consideration, you should just go with a distro you like most, one that feels most 
cuddly or shiny or something.

Jonathon

Philip Laing wrote:
> Thanks BJ ... Now what distro would be more suited these days?  I am looking
> at Fedora or Ununtu ... some may have preferences for viable reasons
> 
> Thanks again ... quick reply to my question ... I think I am going to like
> setting up and configuring OFBiz
> 
> Phil
> 
> 
> 
>> -----Original Message-----
>> From: BJ Freeman [mailto:bjfree@free-man.net]
>> Sent: Tuesday, 2 October 2007 10:29 AM
>> To: user@ofbiz.apache.org
>> Subject: Re: Download SVN Repository
>>
>> first read
>> http://docs.ofbiz.org/display/OFBTECH/Apache+OFBiz+Technical+Production+Se
>> tup+Guide\
>> http://docs.ofbiz.org/display/OFBIZ/How+to+run+OFBiz+as+a+Service
>> may help.
>> then on your linux box
>> load svn
>> some use wget
>> then you can use the svn commands to load ofbiz.
>> http://docs.ofbiz.org/display/OFBADMIN/Demo+and+Test+Setup+Guide
>>
>> Philip Laing sent the following on 10/1/2007 5:06 PM:
>>> Hi Fellas
>>> I am preparing a Linux box with OFBiz + PostgreSQL ... I have had
>> Compiere
>>> and OpenBravo installed on my windows server boxes and have investigated
>>> TinyERP however OFBiz seems to fit in better with my business model
>> which
>>> largely consists of virtual warehousing and drop ship ecommerce.  This
>> is my
>>> first posting in this forum so excuse me if I have missed any protocol
>> or my
>>> questions seem simplistic. So here we go
>>>
>>> 1. How do I download from the required SVN repositories using windows?
>>> 2. Search the list archives for threads other than scrolling through one
>> by
>>> one?
>>>
>>> Thanks in advance
>>> Wikitec
>>>
>>>
>>>
>>>
>>>
> 
>

Re: Download SVN Repository ... Linux distro?

Posted by BJ Freeman <bj...@free-man.net>.

stick with ununtu
you will have night mares with fedora.
just went thru that.
finally did RHE.
And don't use any open source 1.5 sdk.

Philip Laing sent the following on 10/1/2007 6:00 PM:
> Thanks BJ ... Now what distro would be more suited these days?  I am looking
> at Fedora or Ununtu ... some may have preferences for viable reasons
> 
> Thanks again ... quick reply to my question ... I think I am going to like
> setting up and configuring OFBiz
> 
> Phil
> 
> 
> 
>> -----Original Message-----
>> From: BJ Freeman [mailto:bjfree@free-man.net]
>> Sent: Tuesday, 2 October 2007 10:29 AM
>> To: user@ofbiz.apache.org
>> Subject: Re: Download SVN Repository
>>
>> first read
>> http://docs.ofbiz.org/display/OFBTECH/Apache+OFBiz+Technical+Production+Se
>> tup+Guide\
>> http://docs.ofbiz.org/display/OFBIZ/How+to+run+OFBiz+as+a+Service
>> may help.
>> then on your linux box
>> load svn
>> some use wget
>> then you can use the svn commands to load ofbiz.
>> http://docs.ofbiz.org/display/OFBADMIN/Demo+and+Test+Setup+Guide
>>
>> Philip Laing sent the following on 10/1/2007 5:06 PM:
>>> Hi Fellas
>>> I am preparing a Linux box with OFBiz + PostgreSQL ... I have had
>> Compiere
>>> and OpenBravo installed on my windows server boxes and have investigated
>>> TinyERP however OFBiz seems to fit in better with my business model
>> which
>>> largely consists of virtual warehousing and drop ship ecommerce.  This
>> is my
>>> first posting in this forum so excuse me if I have missed any protocol
>> or my
>>> questions seem simplistic. So here we go
>>>
>>> 1. How do I download from the required SVN repositories using windows?
>>> 2. Search the list archives for threads other than scrolling through one
>> by
>>> one?
>>>
>>> Thanks in advance
>>> Wikitec
>>>
>>>
>>>
>>>
>>>
> 
> 
> 
>

RE: Download SVN Repository ... Linux distro?

Posted by Shi Jinghai <sh...@langhua.cn>.

Fedora is still the best. Here are the steps you may ignore:

1. In Fedora 4/5/6, the standard jdk version is 1.4.2. If you want to
update it to 1.5.0, you need to:
1.1 download jdk-1_5_0_12-linux-i586-rpm.bin (not the rpm) from
http://java.sun.com/javase/downloads/index_jdk5.jsp
1.2 chmod 0700 jdk-1_5_0_12-linux-i586-rpm.bin
1.3 ./jdk-1_5_0_12-linux-i586-rpm.bin
1.4 there should be a directory /usr/java/jdk1.5.0_12 with all java
contents
1.5 download java-1.5.0-sun-compat-1.5.0.12-1jpp.i586.rpm from
ftp://jpackage.hmdc.harvard.edu/JPackage/1.7/generic/RPMS.non-free/java-1.5.0-sun-compat-1.5.0.12-1jpp.i586.rpm
1.6 rpm -ivh java-1.5.0-sun-compat-1.5.0.12-1jpp.i586.rpm
1.7 run "alternatives --config java" to select the right jdk version

2. download OFBiz source code and deploy it NOT under root folder.

3. run ofbiz.

Enjoy it. For jdk 1.6.0, the configuration steps are similar.

Regards,

Shi Jinghai/Beijing Langhua Ltd.


在 2007-10-01一的 20:59 -0700，skip@theDevers写道： 
> Instead of Fedora Core, give a look at CentOS.  Its a good deal more stable.
> I have had lots of weird problems with Fedora in the past (usually fixed
> within a few weeks, but still a pain when it happens).
> 
> Skip
> 
> -----Original Message-----
> From: Philip Laing [mailto:philip.laing@ascconsultants.com.au]
> Sent: Monday, October 01, 2007 6:01 PM
> To: user@ofbiz.apache.org
> Subject: RE: Download SVN Repository ... Linux distro?
> 
> 
> Thanks BJ ... Now what distro would be more suited these days?  I am looking
> at Fedora or Ununtu ... some may have preferences for viable reasons
> 
> Thanks again ... quick reply to my question ... I think I am going to like
> setting up and configuring OFBiz
> 
> Phil
> 
> 
> 
> > -----Original Message-----
> > From: BJ Freeman [mailto:bjfree@free-man.net]
> > Sent: Tuesday, 2 October 2007 10:29 AM
> > To: user@ofbiz.apache.org
> > Subject: Re: Download SVN Repository
> >
> > first read
> > http://docs.ofbiz.org/display/OFBTECH/Apache+OFBiz+Technical+Production+Se
> > tup+Guide\
> > http://docs.ofbiz.org/display/OFBIZ/How+to+run+OFBiz+as+a+Service
> > may help.
> > then on your linux box
> > load svn
> > some use wget
> > then you can use the svn commands to load ofbiz.
> > http://docs.ofbiz.org/display/OFBADMIN/Demo+and+Test+Setup+Guide
> >
> > Philip Laing sent the following on 10/1/2007 5:06 PM:
> > > Hi Fellas
> > > I am preparing a Linux box with OFBiz + PostgreSQL ... I have had
> > Compiere
> > > and OpenBravo installed on my windows server boxes and have investigated
> > > TinyERP however OFBiz seems to fit in better with my business model
> > which
> > > largely consists of virtual warehousing and drop ship ecommerce.  This
> > is my
> > > first posting in this forum so excuse me if I have missed any protocol
> > or my
> > > questions seem simplistic. So here we go
> > >
> > > 1. How do I download from the required SVN repositories using windows?
> > > 2. Search the list archives for threads other than scrolling through one
> > by
> > > one?
> > >
> > > Thanks in advance
> > > Wikitec
> > >
> > >
> > >
> > >
> > >
> 
>

RE: Download SVN Repository ... Linux distro?

Posted by "skip@theDevers" <sk...@thedevers.org>.

Instead of Fedora Core, give a look at CentOS.  Its a good deal more stable.
I have had lots of weird problems with Fedora in the past (usually fixed
within a few weeks, but still a pain when it happens).

Skip

-----Original Message-----
From: Philip Laing [mailto:philip.laing@ascconsultants.com.au]
Sent: Monday, October 01, 2007 6:01 PM
To: user@ofbiz.apache.org
Subject: RE: Download SVN Repository ... Linux distro?


Thanks BJ ... Now what distro would be more suited these days?  I am looking
at Fedora or Ununtu ... some may have preferences for viable reasons

Thanks again ... quick reply to my question ... I think I am going to like
setting up and configuring OFBiz

Phil



> -----Original Message-----
> From: BJ Freeman [mailto:bjfree@free-man.net]
> Sent: Tuesday, 2 October 2007 10:29 AM
> To: user@ofbiz.apache.org
> Subject: Re: Download SVN Repository
>
> first read
> http://docs.ofbiz.org/display/OFBTECH/Apache+OFBiz+Technical+Production+Se
> tup+Guide\
> http://docs.ofbiz.org/display/OFBIZ/How+to+run+OFBiz+as+a+Service
> may help.
> then on your linux box
> load svn
> some use wget
> then you can use the svn commands to load ofbiz.
> http://docs.ofbiz.org/display/OFBADMIN/Demo+and+Test+Setup+Guide
>
> Philip Laing sent the following on 10/1/2007 5:06 PM:
> > Hi Fellas
> > I am preparing a Linux box with OFBiz + PostgreSQL ... I have had
> Compiere
> > and OpenBravo installed on my windows server boxes and have investigated
> > TinyERP however OFBiz seems to fit in better with my business model
> which
> > largely consists of virtual warehousing and drop ship ecommerce.  This
> is my
> > first posting in this forum so excuse me if I have missed any protocol
> or my
> > questions seem simplistic. So here we go
> >
> > 1. How do I download from the required SVN repositories using windows?
> > 2. Search the list archives for threads other than scrolling through one
> by
> > one?
> >
> > Thanks in advance
> > Wikitec
> >
> >
> >
> >
> >

RE: Download SVN Repository ... Linux distro?

Posted by Philip Laing <ph...@ascconsultants.com.au>.

Thanks BJ ... Now what distro would be more suited these days?  I am looking
at Fedora or Ununtu ... some may have preferences for viable reasons

Thanks again ... quick reply to my question ... I think I am going to like
setting up and configuring OFBiz

Phil



> -----Original Message-----
> From: BJ Freeman [mailto:bjfree@free-man.net]
> Sent: Tuesday, 2 October 2007 10:29 AM
> To: user@ofbiz.apache.org
> Subject: Re: Download SVN Repository
> 
> first read
> http://docs.ofbiz.org/display/OFBTECH/Apache+OFBiz+Technical+Production+Se
> tup+Guide\
> http://docs.ofbiz.org/display/OFBIZ/How+to+run+OFBiz+as+a+Service
> may help.
> then on your linux box
> load svn
> some use wget
> then you can use the svn commands to load ofbiz.
> http://docs.ofbiz.org/display/OFBADMIN/Demo+and+Test+Setup+Guide
> 
> Philip Laing sent the following on 10/1/2007 5:06 PM:
> > Hi Fellas
> > I am preparing a Linux box with OFBiz + PostgreSQL ... I have had
> Compiere
> > and OpenBravo installed on my windows server boxes and have investigated
> > TinyERP however OFBiz seems to fit in better with my business model
> which
> > largely consists of virtual warehousing and drop ship ecommerce.  This
> is my
> > first posting in this forum so excuse me if I have missed any protocol
> or my
> > questions seem simplistic. So here we go
> >
> > 1. How do I download from the required SVN repositories using windows?
> > 2. Search the list archives for threads other than scrolling through one
> by
> > one?
> >
> > Thanks in advance
> > Wikitec
> >
> >
> >
> >
> >

Re: Download SVN Repository

Posted by BJ Freeman <bj...@free-man.net>.

first read
http://docs.ofbiz.org/display/OFBTECH/Apache+OFBiz+Technical+Production+Setup+Guide\
http://docs.ofbiz.org/display/OFBIZ/How+to+run+OFBiz+as+a+Service
may help.
then on your linux box
load svn
some use wget
then you can use the svn commands to load ofbiz.
http://docs.ofbiz.org/display/OFBADMIN/Demo+and+Test+Setup+Guide

Philip Laing sent the following on 10/1/2007 5:06 PM:
> Hi Fellas
> I am preparing a Linux box with OFBiz + PostgreSQL ... I have had Compiere
> and OpenBravo installed on my windows server boxes and have investigated
> TinyERP however OFBiz seems to fit in better with my business model which
> largely consists of virtual warehousing and drop ship ecommerce.  This is my
> first posting in this forum so excuse me if I have missed any protocol or my
> questions seem simplistic. So here we go
> 
> 1. How do I download from the required SVN repositories using windows?
> 2. Search the list archives for threads other than scrolling through one by
> one?
> 
> Thanks in advance
> Wikitec
> 
> 
> 
> 
>