PMC Architecture Meeting 20100421

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

Date: 2010-04-21
Time: 7AM GMT
Venue: irc #adempiere-team
Support Spreadsheet: Adempiere PMC Architecture
Chat times in GMT-5

Agenda

(unchanged from last meeting)

  • Opinions about unplugging unmaintained or underdeveloped extensions from core (CM, HTML UI, Posterita)
    • Shortly: Who is going to ask community for doing that?
  • Opinions about function based indexes in seed database [1] [2]
  • Continue Review Wishlist
    • only priority high, per topic, starting at #11:
      • author shortly explains topic
      • others agree on priority
      • discussion on first tasks for the topic, put them on the task list
  • One month of PMC meeting: Are we on the right way? Fast enough?
  • Other items?

Summary

  • Removal of unmaintained modules: Low prio since no volunteers
  • Function based indexes
    • Official Position in Release Commit Rules:
    • forbidden to implement validations by FBIs in official seeds
    • allowed for performance improvements in official seeds
  • Wish #11: Security in DB and for pw storing
    • Convert to two FRs
  • Wish #23: Functional testing framework
    • Responsibility of QA group
  • Wish #25: Interfaces to relevant services
    • depends upon #1
    • PoC using Account module
    • interface in Doc_* classes
  • Wish #27: Official vs. customization migration
    • correlated to #8/9
  • Wish #29: EJB -> soap/rest/servlet
    • has to be done during OSGi transition
  • Wish #30
    • already covered by FR 1914013

Chat

(01:31:01) red1 [~red1@250.67.49.60.klj04-home.tm.net.my] entered the channel.
(01:46:26) interopen [~interopen@xiancaro.com] entered the channel.
(01:55:55) viola [~viola@p4FE2EA40.dip.t-dialin.net] entered the channel.
(01:56:15) viola: good morning from germany...
(01:57:23) CarlosRuiz: Hi Jörg
(01:58:31) viola: Are you all well? - We are bringing our big (non-ADempiere) austrian provisioning project into production since yesterday
(01:58:48) viola: so this is an exciting week here at ObjectCode
(01:59:50) CarlosRuiz: great
(02:00:42) viola: ok lets start - agenda is here: http://www.adempiere.com/index.php/PMC_Architecture_Meeting_20100421
(02:00:59) viola: Or we dive into community management again - what do you prefer?
(02:01:57) CarlosRuiz: I prefer to move architectural things
(02:02:24) viola: ... anyone else?
(02:03:02) CarlosRuiz: for the first thing - red1 asked in forums - nobody volunteered - so, I guess we can make the removal of unmaintained modules a low priority task and focus on others
(02:03:07) hengsin [~hengsin@115.164.193.198] entered the channel.
(02:03:19) viola: ok
(02:04:07) hengsin: hi guys, not free today, moving house this week!
(02:04:45) hengsin: will join the meeting next week.
(02:04:46) viola: oh - good luck!
(02:05:03) CarlosRuiz: thanks for letting us know - sounds like your boy is growing
(02:05:34) viola: carlos: added a low prio wish to our (growing) wishlist
(02:05:35) hengsin: gtg, bye all.
(02:05:39) viola: bye
(02:05:43) CarlosRuiz: bye
(02:05:48) hengsin has left the channel (quit: Client Quit).
(02:06:04) viola: next topic: FBI
(02:06:30) viola: question was:
(02:06:41) viola: FBI in seed db?
(02:06:51) viola: then drop validations in code?
(02:07:16) viola: concensus was: not possible, since not all dbs support FBI
(02:07:42) viola: but: include FBIs in seed of dbs supporting them for performance reasons
(02:07:53) viola: but don't frop vaidations in code
(02:07:59) viola: carlos: correct?
(02:08:46) CarlosRuiz: I would say - include selected FBIs that can have great impact on performance
(02:09:08) CarlosRuiz: and forbidden to implement (in official seed) validations using FBIs
(02:10:01) CarlosRuiz: in other words - I agree with what you wrote - I just added the words "selected" and "forbidden"
(02:11:22) CarlosRuiz: if you agree - then, we can say it's official position from this group
(02:14:04) viola: agree
(02:14:16) viola: BTW: What does it mean: official position?
(02:14:32) viola: How do we let all devs know about our position?
(02:15:48) CarlosRuiz: 1 - with such official position I can do peer review with clear rules, I can add a rule also in Release Commit Rules
(02:15:48) CarlosRuiz: 2 - probably post in developer forums can be the best
(02:17:36) viola: ok
(02:19:44) viola: so continuing wishlist high prios?
(02:20:06) CarlosRuiz: yep
(02:20:22) viola: next would be #11
(02:20:52) viola: sounds like a clearly defined task
(02:21:33) viola: could be transformed to an FR?
(02:23:09) CarlosRuiz: let's keep it as a task proposed on architectural group - with the current resources - it will end in nothing out there
(02:23:29) viola: I see
(02:23:58) viola: but there is nothing to discuss here - so increment to #23
(02:24:52) viola: this is more interesting - what tests do we currently have?
(02:24:58) viola: The Fitnesse Suite
(02:25:28) viola: the testadempiere.com site
(02:26:39) viola: test testsuite in extend
(02:26:47) viola: anything else?
(02:27:22) CarlosRuiz: sorry, don't understand - what is #23?
(02:28:16) viola: ahm wish #23 from the wishlist doc: Functional testing framework for swing and web client
(02:28:35) interopen: we have junit tests and some POC to test webui using sahi
(02:28:55) viola: ah can you point me to some wiki page?
(02:28:59) interopen: and setting up a CI testing server to work with, but not yet there
(02:29:14) CarlosRuiz: ah - I was confused - task #11 is related to security as wish #11 :-)
(02:29:45) interopen: all is here http://www.adempiere.com/index.php/PMC:QA in research and documentation section
(02:29:56) viola: oh sorry - I'm iterating the wishlist, not the task list
(02:30:07) viola: interopen: thanks
(02:30:25) CarlosRuiz: my fault
(02:30:48) viola: well by the way: The whole wish #23 is the topic of the QA group, isn't it?
(02:30:55) viola: so maybe we should drop it here
(02:31:12) CarlosRuiz: now I understand why you said #11 as FR  :-)
(02:31:41) viola: but task is ok for it
(02:31:51) viola: BTW: What are we heading for here?
(02:32:06) viola: we are iterating high prio wishes
(02:32:13) viola: converting them to tasks
(02:32:30) viola: and then have an architecture task list (eg for the next release)
(02:32:41) viola: and we are nearly through with it
(02:33:03) CarlosRuiz: yep - now I think #11 can be opened as FR or even as Bug
(02:33:24) interopen: viola: welcome
(02:33:40) viola: ok I will open an FR for it
(02:33:57) CarlosRuiz: two - there are two different issues mentioned in #11
(02:34:26) CarlosRuiz: now - about #23 - yes, I think it's on the scope of QA group
(02:34:31) viola: db encryption an db password store encryption?
(02:34:58) CarlosRuiz: yep
(02:35:09) viola: ok then lets drop it from here (I understand arch has to work together with QA, but no immediate task)
(02:35:27) trifon [~trifon@pD95F0ACA.dip0.t-ipconnect.de] entered the channel.
(02:36:04) viola: #25: That can done if we have a modularization release
(02:36:19) viola: so its equal to #1?
(02:37:32) CarlosRuiz: I would say complementary
(02:38:04) viola: you mean #1 is about plugins=extensions, #25 about core modularization?
(02:38:45) viola: ok but it ends up in the same task
(02:38:46) CarlosRuiz: no, #1 is enabling OSGi - and #25 is checking potential interfaces on modules
(02:39:12) viola: ah you're right
(02:39:18) CarlosRuiz: #25 will use the result of #1
(02:39:25) viola: agree
(02:40:20) viola: in that context: We wanted to use accounting as a first module example for OSGi, remember?
(02:40:26) CarlosRuiz: yep
(02:40:27) viola: How can we tackle that?
(02:41:31) viola: I would identify current interfaces in that area (DocAction and the like)
(02:41:42) viola: and use them as "the accounting interface"
(02:41:57) viola: but then I could miss some points
(02:42:07) viola: isn'm mjudd our "accounting expert"
(02:42:18) viola: can I ask him?
(02:42:37) CarlosRuiz: I see Doc and its children (like Doc_Order) are implemented as an abstract class and the Doc_ implementing the abstract methods createFacts and load*
(02:42:37) CarlosRuiz: that can be moved to use an interface
(02:43:18) viola: yes - that I meant
(02:43:47) viola: is it that simple? or are there other methods used also?
(02:44:17) CarlosRuiz: and we could add some "register" mechanism
(02:44:25) viola: ?
(02:44:53) CarlosRuiz: I see three abstract methods -> loadDocumentDetails, createFacts and getBalance - nothing else
(02:45:01) viola: ok fine
(02:45:02) CarlosRuiz: I mean "registration" mechanism
(02:45:17) CarlosRuiz: currently we
(02:45:32) CarlosRuiz: hmmm - that changed in last version
(02:45:55) viola: Then I would create an extension point for that and a new "accounting plugin" project and move the code there
(02:46:01) viola: I'll try that
(02:46:15) CarlosRuiz: in past version we cannot add easily documents, we needed to change core to add a document, because there were strict references (hardcoded) to the Doc_ class
(02:46:27) CarlosRuiz: but in last version I moved that to standarize the name of the Doc_ classes
(02:46:45) CarlosRuiz: and now we're using the tablename to construct the Doc_ class name
(02:46:55) CarlosRuiz: and we take all the tables with a "Posted" columns
(02:47:10) viola: I would turn that around:
(02:47:23) CarlosRuiz: so, at this moment the "registration" is having a "Posted" column
(02:47:43) viola: A plugin can register an Extension - declaring on which table it wants to implement the three method
(02:48:13) trifon: it should register for specific document type.
(02:48:15) CarlosRuiz: yep - that was what I was trying to mean with "register" mechanism
(02:48:30) trifon: here comes question the we need to allow registering of document types.
(02:48:35) viola: ah yep Doc Type instead of table
(02:48:50) viola: ok that is sufficient for me to start, thanks
(02:49:00) CarlosRuiz: at this moment is per table
(02:49:15) CarlosRuiz: moving to Doc Type will need probably code movement
(02:49:31) viola: I'll take a look into that
(02:50:27) viola: I have the feeling we could finish the wishlist today - sorry for hurrying
(02:50:50) viola: but we have only #27 and #29, and I hope they are simple
(02:51:25) viola: ok?
(02:51:40) CarlosRuiz: yes
(02:52:14) viola: because I think #27 is equal to #8/9
(02:52:54) CarlosRuiz: no I think #27 is different
(02:52:54) CarlosRuiz: it was being discussed by trifon and hengsin in a past meeting
(02:53:08) CarlosRuiz: proposing perhaps to have a customization extension table
(02:53:26) CarlosRuiz: that overwrites some columns from AD_Column, or AD_Field, or AD_tab, etc
(02:53:42) viola: I remember but that is the solution to #9, too?
(02:54:05) CarlosRuiz: I suppose it can be a mechanism similar to the AD_Field_V currently in adempiere - where fields overwrite some values from columns
(02:54:07) viola: but you're right: it is a different requirement
(02:55:45) CarlosRuiz: I think JJ tried to manage that with the change log - marking customizations on dictionary changes - and allowing to re-execute those customizations after upgrading a release
(02:56:39) viola: yes but: Isn't that one hot spot #8,#9 and #27 for which we should provide one such solution as you sketched
(02:57:42) CarlosRuiz: for #8 and #9 I suppose the solution is 2pack, 3pack or something similar
(02:58:02) CarlosRuiz: for #27 is something different - adding things in dictionary
(02:58:17) CarlosRuiz: then 2pack must implement how to import/export that new things
(02:58:54) viola: #9 is about conflicts between modules - that is just like a conflict between one module and the core
(03:00:11) viola: but ok maybe this requires more research
(03:01:48) CarlosRuiz: #29 and #30?
(03:02:37) viola: #29 to is clear
(03:02:50) CarlosRuiz: yep - you opened a forum thread for that
(03:03:02) viola: naturally I would like to add OSGi remote services as an impl alternative
(03:03:40) CarlosRuiz: sure
(03:03:45) viola: ? no I stated in the equinox thread that I am having problems with the EJBs
(03:04:08) CarlosRuiz: yep - and hengsin and trifon answered that it's ok to remove ejb - I agree also
(03:04:18) viola: ok
(03:04:30) CarlosRuiz: remove -> replace
(03:04:37) viola: so we are through with the high prio tasks
(03:04:52) CarlosRuiz: #30 is top priority?
(03:04:56) viola: na... not through... ;-)
(03:04:56) viola: but we took a look at them
(03:05:17) viola: hmm
(03:05:37) CarlosRuiz: I think it is to ease the callout implementation on OSGi - it must have an open FR somewhere
(03:05:48) viola: sorry forgot about that
(03:06:10) viola: don't think there is an FR for that
(03:06:54) viola: If it is ok to solve it in the OSGi context - understood
(03:07:03) viola: if not - what is the point?
(03:07:32) viola: ah we again hijack the QA meeting
(03:07:46) viola: carlos: Lets postpone #30 to next week
(03:07:52) CarlosRuiz: ok
(03:08:07) viola: and then I would like to resume our work and identify
(03:08:14) viola: the high prio hot spots
(03:08:21) viola: I think there are only 3
(03:08:33) viola: and then concentrate on them for the next release
(03:08:46) CarlosRuiz: this is the FR
(03:08:46) CarlosRuiz: https://sourceforge.net/tracker/?func=detail&atid=879335&aid=1974963&group_id=176962
(03:09:11) CarlosRuiz: hmmm - better this one
(03:09:11) CarlosRuiz: https://sourceforge.net/tracker/index.php?func=detail&aid=1914013&group_id=176962&atid=879335
(03:09:34) viola: ah ok thanks - i have to take a look
(03:09:52) CarlosRuiz: ok - thanks a lot for this meeting
(03:09:58) viola: thanks!
(03:10:00) viola: bye
(03:10:02) CarlosRuiz: bye
(03:10:11) viola has left the channel.