I agree completely with Victor's words.
-> "sacrificing the runtime flexibility for the sake of performance"
it's a very strange phrase, it sounds very weird for me, for me it's a clear
statement about putting technology over functionality
Much of the times "performance" is a matter of user feeling, if you compare
an old COBOL based system (there are a lot of this here in Colombia) vs. a
3-tier system. ALWAYS the "feeling of performance" of COBOL based system is
faster, that's a matter of architecture.
I've worked with Compiere/Adempiere and really I don't feel the
"performance" problem is so big to make fundamental changes because of that.
I know that there are SOME points for the system to be enhanced, i.e. this
week Joel and me discovered a big problem with tree management in financial
reports. But these are specific points to enhance, not the whole system.
And I want to repeat until infinite, we have a legacy here, WE MUST NOT
DESTROY. We must enhance, "embrace and extend".
For me is a BIG BETTER approach (not enoughly published) the WAN connection
enhanced by Hengsin
Hengsin has made big enhancements on performance without destroying nothing
of the goodness of Compiere.
For me is BIG BETTER approach the lazy load tabs development in course from
Hengsin, than a "sacrifice on flexibility"
And even is better for me if we ADD this type of things to the system, in a
configurable way, this is, allow the implementor choose the desired approach
according to the nature of the project.
I mean we can have a slow but flexible client (very useful for some
projects, or for initial stage of the project when things change very
And at the same time we could have a very fast but inflexible client - maybe
because is pre-compiled (useful for stable projects or phases)
It's a matter of the way you think when designing. You can design new
things without destroying the system, without destroying current stable and
very tested functionality, and current
----- Original Message -----
From: "Victor" <victor.perez@...>
To: "Bahman Movaqar" <b.movaqar@...>
Cc: <adempiere-tang@...>; <team@...>
Sent: Wednesday, February 07, 2007 11:43 AM
Subject: Re: [Adempiere-tang] Radical idea
> I agree not with sacrificing the runtime flexibility, this is very
> important. I worked in the past with propietary ERPs this way and it is
> pain head, they use one program to windows and is complex to maintain.
> I think we should use best tools to development ie MDA, but we should
> think always in end user.
> Now in adempiere you can create new windows, tabs , field, etc in minutes
> , this feature is very nice to end user and any IT Management, they need
> not guru or expert to make any this changes.
> I think that performace with runtime is solve with cache and optimization.
> AD and runtime let one engine business core as rock solid, when you have
> it verys stable your aplicaction also is.
> AD and runtime is main different vs another ERPs , Only SAP working the
> same way, I think this model is functinal and great.
> one example is EJB2, it was to complex you need one expert to management,
> then EJB#3 is re think and best.
> agin any things we wiil make should are base in end user.
> this should easy, fast, flexible.
> if we to go with idea sacrificing the runtime flexibility we lost very
> Victor Perez
> Bahman Movaqar escribió:
>> I absolutely agree with you on sacrificing the runtime flexibility for
>> the sake of performance. It's a much faster approach which uses static
>> windows that don't need to connect to DB to fetch their widget's
>> In addition After a period of corrections and development, ADempiere
>> will become a stable version equipped with new technologies and shall
>> experience a period of lesser changes. That's the time when people see
>> no notable huge difference in each release with its prior ones thus
>> looking at things like performance.
>> The only issue with this style of development is the development style
>> itself which requires a re-build at each change.
>> It may seem rather idealistic however I would suggest a reverse
>> approach: Designing a UML model of the system and generating code and
>> DB from it. This approach is more flexible since it allows us to
>> define the business in a more natural way, beginning from UML models,
>> while the above approach forces us to first design the DB and then he
>> logic, sounds somewhat non-natural to me.
>> Besides adding modules and plugins to ADempiere will be more logical
>> and easier. Just design the module and generate the code. And about
>> business rules in this approach, they may be created using the same
>> modeling tools since they allow you to define the details of the
>> relationships and usages.
>> This way the solution will have somewhat a MDA (model-driven
>> architecture) which sounds very impressing looking towards the market.
>> It will be a new method of developing business solutions reliably.
>> Also we can make some tools to help designers generate the DB
>> structure from the model.
>> Warm Regards,
>> Using Tomcat but need to do more? Need to support web services, security?
>> Get stuff done quickly with pre-integrated technology to make your job
>> Download IBM WebSphere Application Server v.1.0.1 based on Apache
>> Adempiere-tang mailing list