PMC Architecture Meeting 20100224

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

Date: 2010-02-24
Time: 6AM GMT
Venue: irc #adempiere-team
Support Spreadsheet: Adempiere PMC Architecture
Chat times in GMT-5

Agenda

  • Carlos: Any impacts from other PMC meetings?
  • Review Wishlist
    • only priority high, per topic:
      • author shortly explains topic
      • others agree on priority
      • discussion on first tasks for the topic, put them on the task list
  • Other items?

Summary

  • Joel (functional team) started specification template
  • Wish #1: Make Adempiere modular
    • Should provide modularization interfaces
    • OSGI one possible implementation
    • dictionary migration at plugin install time required - possibly via 2pack
    • Task for joerg viola: write a sketch
  • Wish #2: Scalable Windows
    • Workarounds exist, problably this is not architecture related
  • Wish #7:
    • Workarounds exist, problably this is not architecture related

Chat

(02:08:21) phib: what's the agenda?
(02:08:41) viola: tried to put one up here: http://www.adempiere.com/index.php/PMC_Architecture_Meeting_20100224
(02:09:10) viola: essentially discussing the wishlist here http://spreadsheets.google.com/pub?key=tFef7xeNzas8eKEws8SPH0A&output=html
(02:09:47) phib: looking...
(02:09:51) hengsin: phib: feel free to add more items to the wish list
(02:10:18) CarlosRuiz: hengsin: do you agree with the proposed agenda?
(02:10:59) hengsin: yes
(02:11:18) viola: phib: agenda ok?
(02:11:36) phib: yes
(02:11:50) viola: ok then: Carlos: Any input from other PMC meetings?
(02:12:04) CarlosRuiz: ok / so, first point:
(02:12:04) CarlosRuiz: impact from other PMC meetings
(02:12:04) CarlosRuiz: Joel (functional team) is starting the draft for the specification template
(02:12:32) CarlosRuiz: there are different wishlists on teams - so maybe we can think later on creating just one categorized and combine it
(02:12:33) viola: ahm - that means...?
(02:13:48) CarlosRuiz: viola: that means that our task #7 is being started in functional team, we'll review later with whole PMC Joel's proposal
(02:14:13) viola: ok!
(02:15:03) viola: about combining wishlists: Thats ok for me later - for now the groups should do their homework...
(02:15:39) viola: Carlos: Anything else?
(02:16:06) CarlosRuiz: nope - I don't recall any other impact at this moment
(02:16:35) viola: ok thanks - then lets walk through the wish list, prio high
(02:17:03) hengsin: jorg: I've change your "plugin" entry prio to high
(02:17:15) hengsin: so I guess you can start with that first :)
(02:17:24) viola: #1 - maybe together with #25: goal is to make adempiere more modular
(02:17:30) viola: as u all know
(02:17:51) viola: prio 1 means: starts immediately - is that ok for all?
(02:17:54) hengsin: I notice u have done 2 approach, are they the same status ?
(02:18:11) viola: approach 1 is more or less stable
(02:18:24) viola: an osgi container inside adempiere
(02:18:44) viola: but extending this approach to extract more and more functionality
(02:18:52) viola: out of the core is complicated
(02:19:00) viola: so I started the 2nd approach
(02:19:13) viola: running adempiere inside an osgi container
(02:19:25) viola: currently ok for swing and webstart
(02:19:34) viola: problems with zw web ui
(02:19:41) viola: sorry zk web ui
(02:19:58) viola: but: OSGI is only one possible infrastructure
(02:19:58) hengsin: viola: if approach 2 is better, I can looks into the zk problem
(02:20:13) hengsin: also, wouldn't the ejb stuff a problem too ?
(02:20:15) viola: would be cool
(02:20:35) viola: ejb and osgi is a nogo more or less
(02:20:48) viola: the ejbs have to run outside the container
(02:20:58) CarlosRuiz: question: must we add specifically OSGi to the #1? or there are other potential approachs for #1?
(02:21:09) viola: thats important:
(02:21:18) viola: OSGI is only one possible infrastructure
(02:21:31) viola: we should immediately start modularizing the core
(02:21:39) viola: by introducing standard java interfaces
(02:21:49) hengsin: carlos: the thing is there are no other contributor :)
(02:21:57) viola: and one special locator interface to look them up
(02:22:57) viola: all: do you agree?
(02:23:02) CarlosRuiz: at least our wishlist #1 is OSGi / if other appears then we can add them to the list
(02:23:04) hengsin: viola: what you proposing is still using the eclipse style extension mechanism right ?
(02:23:33) hengsin: carlos: yes, if there but currently there are no other proposal
(02:23:51) viola: first i propose using java standards for modularizing
(02:24:12) viola: then later we can implement that - yes equinox is my choice now
(02:25:14) hengsin: jorg: using OSGi, we can define a sandbox environment for the plugin ? for e.g, they can't override core classes like PO.java
(02:26:01) viola: they can of course for their own use, but not for others - yes
(02:26:18) CarlosRuiz: viola: DocAction, Callout, ModelValidator / they're interefaces currently / do you mean detecting other points where we need to change the approach and create proper interfaces and change java code to use them?
(02:26:18) CarlosRuiz: --> just trying to understand the work needed there
(02:26:55) hengsin: ok, thats great, I think it is critical that we can define what module can and can not do and enforce where possible at runtime.
(02:27:07) viola: carlos: yes but the code that looksup DocActions, Callouts and such is explicit
(02:27:36) viola: if we had an Interface ICalloutFinder - one could implement an OSGI version of it
(02:28:06) viola: hengsin: exactly that should be possible
(02:29:09) viola: carlos: that can be ongoing work: replacing all explicit "new XXX()" by looking up the appropriate implementation
(02:29:38) viola: PROPOSAL: Add a task for me to write down this proposal in more detail and review it in the next meeting
(02:30:01) CarlosRuiz: ok
(02:30:05) hengsin: viola: I notice in your earlier prototy, there is 2pack support, is that still in and supported ?
(02:30:26) viola: it is easy to do the same in the 2nd approach
(02:30:31) viola: just copy n paste
(02:30:48) hengsin: ic but is that what you intend to do or you have other idea ?
(02:30:49) viola: and yes - that must be part of a plugin infrastructure
(02:31:18) hengsin: I remember you mention one time that 2pack might not be the prefer approach
(02:31:36) viola: i intend to do that though i would try to factor out 2pack - and make that replaceable
(02:31:54) viola: on the summer conference people told me to use other approaches
(02:32:02) viola: I am not in that
(02:32:02) hengsin: which is ?
(02:32:38) viola: ahm
(02:33:05) viola: currently unaware weren't there other pack to update dictionary
(02:33:10) CarlosRuiz: I can't see easily another approach to accompany a package with dictionary changes
(02:33:39) viola: well obvioulsy SQL migration scripts were a second approach though not preferrable
(02:33:49) viola: only in very easy situations
(02:33:55) CarlosRuiz: which are the possibilities there? when a 2pack is applied, every time the container is started, or when the package is changed?
(02:34:17) viola: when a package with a new version number is installed
(02:34:45) CarlosRuiz: that's why I don't see another possible approach - how to know which migration scripts were already ran?
(02:34:56) viola: ok
(02:34:59) phib: viola, were you thinking of this: http://www.adempiere.com/index.php/AD_Migration?
(02:35:06) CarlosRuiz: 2pack can cope with rerunning a package - but migration scripts don't
(02:35:14) phib: i got to beta stage, and haven't had time to pursue
(02:35:31) phib: alpha
(02:35:36) phib: very alpha
(02:35:44) viola: phib yes thanks and also these: http://www.adempiere.com/index.php/XML2AD
(02:36:07) viola: i didn't mean to decide about these approaches
(02:36:18) viola: i just should be possible to plug them in
(02:36:22) hengsin: phib: that looks like a command driven approach, right ?
(02:36:29) viola: at the time a plugin is installed
(02:36:51) phib: hengsin, what do you mean by command driven?
(02:37:18) hengsin: i.e it records the action/command needed in the xml file
(02:37:26) phib: currently it behaves like the sql migration script generator
(02:37:45) phib: the plan was to be also able to generate script from existing entries, changelog, etc
(02:39:09) trifon [~chatzilla@p54919DC4.dip0.t-ipconnect.de] entered the channel.
(02:39:19) viola: ok I have added the task next item of the wishlist?
(02:39:26) CarlosRuiz: ok, I would propose to make a task for that - review potential approaches for accompanying a package with dictionary and db changes
(02:39:40) viola: thats good
(02:40:43) CarlosRuiz: done  :-)
(02:40:48) viola: gents? can we go on?
(02:40:56) CarlosRuiz: sure, please
(02:40:57) hengsin: phib: alright, it is to record the database change log, I guess that would only work well if we version our db seed and then you can define properly the version dependency
(02:41:39) viola: then: Wishlist #2
(02:42:00) viola: added by me cause topic on forums lately but i have no insight
(02:42:05) phib: hengsin, i was thinking more that each package/module/entity type should have its own version
(02:42:16) viola: maybe identical to #7 - hengsin?
(02:42:38) CarlosRuiz: #2 -> wondering if priority is really "high" - Trifon mentioned in mail that restricting # of records in role works
(02:42:40) hengsin: phib: lets work on that later, I'm talking about db version dependency.
(02:43:09) hengsin: I have already implemented a virtual table mechanism in trunk, it needs to be verify further but it is there
(02:43:40) CarlosRuiz: is zkwebui currently using the virtual table mechanism?
(02:44:15) phib: i saw there was a problem with oracle?
(02:44:25) CarlosRuiz: ah, it's in GridTable, it would work on swing and zk
(02:44:26) hengsin: my current implementation doesn't use paging but instead of loading everything into memory, it only load the PK first. A subset of the records are then loaded and cache in memory using the PK
(02:44:51) hengsin: phib: for window, there are problem with postgresql, only fix today.
(02:45:37) hengsin: for Info, it is only done for zk, it is using database paging. I have a problem on that with Oracle but I will commit a workaround today.
(02:46:10) hengsin: carlos: yes, I turn it on for swing in trunk today so that other can test it.
(02:46:10) viola: so do we have an architectural pitfall here or "simply" an enhancement - in latter case it should not be on the wishlist?
(02:46:37) hengsin: Jorg: I didn't see how is that "architecture related" ?
(02:47:05) viola: hengsin: ok then lets remove that from the list - ok?
(02:47:12) CarlosRuiz: ...
(02:47:21) hengsin: I means you can do virtual table, paging, etc in sql or hibernate etc
(02:47:37) viola: ok
(02:47:54) viola: done!
(02:48:07) CarlosRuiz: I guess it becomes "architectural" because there is an ongoing discussion stating that other approaches allow paging by default (no need to implement it)
(02:48:40) CarlosRuiz: do you think that must go to usability or functional wishlists?
(02:49:33) hengsin: carlos: I guess it is more how do we stage this through QA ? It have an implementation now but we need verification and feedback
(02:50:02) CarlosRuiz: ah, ok / then let's continue
(02:50:21) viola: hengsin on wish #7?
(02:51:11) CarlosRuiz: viola: Info Windows are very prone to be customized in each implementation
(02:51:19) hengsin: only implemented for zk using db paging, pending swing
(02:51:38) hengsin: again, need qa and feedback too
(02:51:57) CarlosRuiz: Compiere implemented an approach to allow user to add columns to Info Window via configuration
(02:52:23) CarlosRuiz: I guess Heng Sin is proposing something to solve that for Info Windows here
(02:52:31) CarlosRuiz: am I right hengsin?
(02:52:37) phib: #16
(02:52:49) hengsin: carlos: This popup on my mind now, we need a proper environment to do performance and scalability testing ( not to mention it is time consuming and tedious ), is there possibility for this to be setup ?
(02:53:19) hengsin: no, carlos, that's #16
(02:53:43) CarlosRuiz: ah, ok, so I also need explanation for #7 :-)
(02:53:52) hengsin: carlos: I'm talking allowing the Info window to handle very large result set like millions of row ...
(02:54:04) CarlosRuiz: ah, related to #2
(02:54:32) CarlosRuiz: are Info Windows respecting the max # records in role ?
(02:54:44) hengsin: yes, it does
(02:54:55) hengsin: so you have a decent workaround here
(02:54:56) viola: hengsin: testing many clients is hard, but testing large dbs should be simple - just setup a large seed db
(02:55:36) hengsin: viola: yes but preferably we have a control environment and somebody to test and publish it
(02:55:58) hengsin: that will avoid a lot of confusion in the community
(02:56:56) viola: hmmm - someone must volunteer for that - carlos: topic for QA group!
(02:57:12) CarlosRuiz: I asked for a test env for performance, and offered my help to try solutions - but nobody answered, and this is a specific business case, so we can wait, and call for a sponsor in community with such test env - I don't see the hurry if the most interested party (business deal) is not in a hurry
(02:57:32) viola: thats right
(02:57:36) hengsin: agree
(02:57:42) viola: sorry guys i have to leave
(02:57:49) hengsin: lets move on to #8 ..
(02:58:06) viola: about #25: see it in conjunction to #1
(02:58:18) viola: i will talk about that in the proposal
(02:59:12) CarlosRuiz: ok, we can check that on next meeting then
(02:59:47) viola: carlos: you publish the transcript, i will then write to summary
(02:59:51) viola: bye!
(02:59:54) hengsin: bye
(02:59:57) phib: bye
(03:00:00) CarlosRuiz: thanks Jörg
(03:00:05) CarlosRuiz: thanks Paul, Heng Sin
(03:00:06) viola has left the channel.
(03:01:05) phib: i've gtg too -- see you next week
(03:01:14) CarlosRuiz: bye guys, thanks a lot for attending
(03:01:35) phib has left the channel (quit: Quit: Leaving).