Talk:The Adempiere Next Generation (TANG)

From ADempiere
Jump to: navigation, search
This Wiki is read-only for reference purposes to avoid broken links.

TANG or not to TANG

And one question is if rewriting is right way to go. Would progress using small steps be better (like many Compiere veterans have stated).

--kontro 19:00, 14 March 2007 (EDT)

I wouldn't say it is better but it is more realistic to do it in small steps.
--hengsin March 16, 2007 at 00:40 (UTC)
U can start with a completely new rewrite, then improve it in small steps. It wouldnt impact ADempiere if done from scratch even while as long letting ADempiere proceed oblivous to TANG. The issue arises when we ask ADempiere to stop all development and focus on TANG, then Hengsin's words apply. But after listening to u, i would ask, "What does your heart say?" - Red1 12:32, 16 March 2007 (EDT)
Today my heart says that you will be amazed in Berlin.
--kontro 03:31, 17 March 2007 (EDT)

Size of tang compared to Adempiere3

I have feeling that size of tang project is not that huge after all. So much of Adempiere's functionality can be solved using "off the shelve" components (persistence, transaction, Gui modeling, remote use, security ...).

--kontro 06:50, 17 March 2007 (EDT)

Informative irc chat

<agramdass> Kontro, may I know how you forsee the integration of EJB3 with ADempiere
<kontro> positively :)
<kontro> Hard part is supporting more than one j2ee server.
<agramdass> so you mean clustering
<huehner> or different vendors' ejb server?
<agramdass> Do you intend to inject the ejb annotations directly in the BL models???
<kontro> I mean different vendors.
<agramdass> ok
<kontro> Depends on what you mean by Business logic model.
<kontro> Most of the none CRUD BL will be in rules engine rules or workflow/bpel rules.
<kontro> But basic CRUD stuff will be @Session @Entity annotated objects.
<agramdass> ok
<kontro> I am planning to put all default settings in annotations so everything 
         that is in deployment description files is installation time customizations.
<kontro> Also going to make it possible (not compulsory) to spread storage in 
         different databases. Like transactional entities on server wit SAS15K 
         drives and change history on server with ideraid.
<kontro> So that not all entity classes wont be in same persistence unit.

<kontro> In some places there could be also interceptor objects which 
         execute javascript from deployment description.
<kontro> One tough question is that would it be possible to interfere entity 
         class loading so that runtime bytecode manipulation instructions 
         could be read from settings.
<kontro> It would allow adding some columns to entities without need for recompiling.
<agramdass> yeps, saw that you posted this problem previously
<agramdass> currently I am quite novice in terms of EJB
<kontro> Planning to use j2ee server's administration console as main customization GUI.
<agramdass> but learning gradually
<agramdass> that's why I wanted to know the direction in which you intend to go
<kontro> I am using following jsr specs: 220,222,224,244,181 and 109.
<kontro> If there is need to check how are those implemented I use hibernate, jboss and glassfish.
<kontro> Also testing with toplink, but not interested about its extended features.
<kontro> Nonstandard features like workflow engine and rules engine is going to be accessed using webservices.
<kontro> So that we can easily support different vendors designs.
<kontro> Today I feel like letting JBI (java business integration) to mature.
<kontro> I also get lot of questions about SPRING, but so far I have not convinced.
         Spring have awesome feature set, but since best features are sucked into 
         EJB3 I am not sure.
<agramdass> yeps, investigated about SPRING some tme back
<kontro> If red1 would be online he would say that I should write all this on wiki - and he is right.
<agramdass> yeps

--kontro 10:25, 18 March 2007 (EDT)

Security and data integrity

Ogryb's idea of providing hql interface for web service client has two problems (if I have got it right).

If client can make dynamic hql queries then the server has to parse manually whole query string to find out what entities user is fetching. After we know what entities he wants to query we have to find out if client has rights to access those entities.

If data modifications are allowed through ws-hql interface then client end is responsible of data integrity. Data integrity is very important thing and I think it should be handled in one place. See here [1] how nasty things can get.

Maybe we could have discussion about these issues on TANG mailing list?

I think there are way too much emphasize on the important and usefullness of porting to ejb3 and jpa ( I seriously doubt moving to jpa is the right thing to do as it will required a rewrite of most of the current business rule and processes - majority of them are sql driven now). To me, the biggest issue that need to be tackle is the lack of a standard module/extension architecture ( something like osgi and jpf ). Ability to do easy and maintainable customization or extension of ADempiere is very important and more emphasize should be put into this area for tang.
Hengsin 08:46, 5 April 2007 (EDT)

Status of Talk page

I rollback Kontro's deletion of this important talk progress prior to this statement. It is now an archive. History no matter how wrong should not, nay, cannot be erased. In time to come it serves much future research the true thoughts of our geniuses and pioneers. Imagine what happened if someone erased the whole history of Genghiz due to his rapes that causes many ppl today possessing his Y chromosone. China has done such acts of burning books and burning scholars, and today suffers the consequence of depletion of culture. I have read Kontro's new article page. It sounds progressive. And it should have been in this talk page. Article pages are meant to be formal and final, not conversational as this. I shall help to move that direction. Once my dummy mind figures out what in the world he is mumbling about - - Red1 18:48, 6 April 2007 (EDT)

Firefox history

Not trying to implied anything, just a small correction on the firefox story - firefox is not a complete rewrite from scratch, it still share a lot of code base with the original mozilla browser ( Most significantly, the Gecko layout engine ). Read the history here [2] and here [3] Hengsin 01:31, 7 April 2007 (EDT)

Thanks for correction. My information is from O'Reilly's book "Open Sources 2" which I read couple months ago.
--kontro 03:40, 7 April 2007 (EDT)
I did review that book and remembered it all wrong:

1.1.1. Updating the Codebase

About six months into the project, it became clear that the codebase 
was in need of updating. By late 1998, the inherited code was several
generations old, had been patched over and over, and actually hindered
ongoing innovation. Old and fragile, it looked backward toward the 
beginning of the Web, rather than forward to the new technologies a 
modern browser would need to support. So, in late 1998, a painful 
decision was made to rewrite the layout engine, a critical and 
complex core component.

This decision changed the scope of the project dramatically. 
The initial project was an incremental upgrade from the Netscape 
Communicator 4.x product line to a proposed 5.x product line. Moving
to the new layout engine (known as Gecko) meant that the incremental 
model was gone; the Mozilla project would need to develop a complex 
new layout engine and then build a new browser application on top of it. 
And things got harder from there. As the new layout engine began to mature, 
it became clear that other significant parts of the codebase would also
need rewriting. The development process turned out to be a lot like 
a remodeling project where fixing one problem leads to another. Then came 
the long, slow grind to producing something useful (Mozilla 1.0 in June 2002) 
and finally something great (Mozilla Firefox in November 2004).

Mitchell Baker

--kontro 04:01, 7 April 2007 (EDT)