incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ahmad Khalifa <>
Subject Re: Business Framework Project
Date Wed, 23 Jan 2008 00:31:21 GMT
David E Jones wrote:
> The idea of putting all business level stuff in the database is 
> interesting, but I'm still a skeptic. You can certainly build revision 
> control around it, but how do you get the same combination of off-line 
> and remote work along with team collaboration and group effort 
> synchronization? I guess you could build that too, ie some sort of 
> database sync/merge. I have never done this formally, but based on 
> discussions and informal cost/benefit comparison... well... I guess it 
> is enough to say that I'm still a skeptic. ;)

Basically object definitions are grouped together in /Projects/. For an
application developer to start working on any object definition, he has
to have the project that they reside in locked. Add to that a 'Project'
import/export feature, and you can have team collaboration.
A typical scenario would be developer A wants to work on the /Contact/
objects. First he locks the project on the DEV server, imports latest
version to his local environment, works on it, exports working copy back
to the DEV server, unlocks the project.
This is also how you would migrate between different environments.
i.e development to production.

Import/Export operations are saved as files on the server
automatically, but in the future, there could be some sort of revision
control integrated with it.
The import/export files are readable XML files :)

> There are various commercial vendors doing this sort of thing. Most are 
> aimed at having doing infrastructure for a centralized ASP-style 
> environment, ie where there is one big application and people build or 
> extend apps through web-based interfaces and everything lives on the 
> server. The ultimate in lock-in, and an nice enabler of 
> over-centralization (which I think most open source proponents realize 
> the danger and downside of...). That's a good motivation for database 
> driven business data structures, logic, screens, etc.

What could be considered as lock-in or over-centralization from one
perspective, could be looked at as being simplifying things or reducing
costs from another perspective.
Think of CRM/ERP/Accounting/Payroll/HR/etc.. just compressed into one
system, this would certainly promote less Excel sheet usage :)

The basic model of having 1 repository of customers is inherently better
than having multiple repositories at several systems, with data
fragmented allover, and backend migration/integration processes running.

As you mentioned, yes, there *are* various commercial vendors doing
this, but no open source has this capability.

Consider a small-medium business that has an ERP system, and one day
decides that they want to get a CRM system to track their sales force.
Which would be the best scenario of those?
(A) - A typical CRM implementation with data migration/integration work,
       user training, More systems to support.
(B) - A small CRM implementation with no data migration/integration, not
       much user training, no more systems to support.

> Anyway, the two commercial companies that come to mind who are doing 
> things this way are Tenfold Software and Bungee Labs.

Tenfold is similar, they have the same concept of a repository
stored in a database, with multiple applications residing in that 

Bungee labs, are doing something that is somewhat different. From what I
understand, It's a tool that is similar to what MS Visual Studio gives
you when developing ASP.NET applications.

> BTW, Compiere actually works more or less this way. Ie, things are 
> heavily database-driven.

Yup, but they're mainly ERP, and they work with Oracle databases and
some postgreSQL fork. Plus, they don't have the extreme customization
abilities discussed.

> If you get to the point where you start looking at data modeling and the 
> logic tier stuff, feel free to collaborate with us at OFBiz. More eyes 
> on this stuff is always a good thing! Okay, well 98% of the time. ;)

What do you mean by 'start looking at data modeling'?

Are you still skeptical about using database to store application
objects? Consider moving the component-load.xml file to the database
and having a load-on-demand button somewhere. How much easier would it
be for users to activate/deactivate/upgrade components? and no downtime!
This would be exactly like Drupal's Module management system.

Anyway, I really hate the idea of having /Yet Another Framework/, but as
we discussed, there is no open source alternative. This is only found in
commercial applications.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message