> 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, [EMAIL PROTECTED] 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:[EMAIL PROTECTED]
Sent: Wednesday, October 03, 2007 11:12 AM
To: [email protected]
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, [EMAIL PROTECTED] 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:[EMAIL PROTECTED]
Sent: Wednesday, October 03, 2007 3:06 AM
To: [email protected]
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

[EMAIL PROTECTED] sent the following on 10/2/2007 8:55 PM:
BJ

SWT as in Eclipse SWT?

Skip

-----Original Message-----
From: BJ Freeman [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 02, 2007 8:26 PM
To: [email protected]
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













Reply via email to