Difference between revisions of "PMC Architecture Meeting 20100421"

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

Revision as of 11:55, 21 April 2010

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

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.