Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
Locked
123
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
123
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
 
|
Okay so once I saw this I took the 5 minutes necessary to look at eBay's services and start thinking that this commit is a bad idea.
Please correct me if any of the following is wrong: - When you originally brought this up, you described the problem as one of XML vs. API but I think what you actually meant is eBay SDK vs. using XML directly? - You mentioned that the API (SDK) provides additional functionality but it appears to me that it simply abstracts the use of raw SOAP or XML when interacting with the actual API? Based on this I'm not sure that we should have separate components but that the XML based component should just be moved to using the SDK (assuming there are only advantages and no disadvantages in doing so). Doing anything else will just result in twice as much code to maintain with both components doing the same thing (or worse yet, similar things but with huge differences in implementation from the user's perspective). Converting the existing XML integration to use the SDK will ensure that we have a single solution in place and that no functionality in the existing component is lost. Regards Scott HotWax Media http://www.hotwaxmedia.com On 2/02/2010, at 7:16 PM, [hidden email] wrote: > Author: hansbak > Date: Wed Feb 3 03:16:07 2010 > New Revision: 905876 > > URL: http://svn.apache.org/viewvc?rev=905876&view=rev > Log: > move the java api functions from the existing ebay component to the new ebaystore component: no functional changes > |
smime.p7s (3K)
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
|
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
|
|
Hi Hans,
Don't get me wrong, if the SDK simplifies the integration then I am all for it. I don't however think that your approach is a good one, IMO the most likely outcome will be that your implementation will be substantially different from what is currently available and because of that we will end up with both implementations in the trunk for a very long time and anyone who wants to integrate eBay will be faced with the task of assessing both. To be frank, I think you're taking the path that is easiest for you but much more difficult for the community going forward. Regards Scott On 2/02/2010, at 8:05 PM, Hans Bakker wrote: > Hi Scott, > > I am also not sure if we need 2 components. That can only be decided by > the users of the original Ebay component isn't it? I do not know the > user requirements of the original ebay component. > > Now we moved the new functionality to a separate component it is getting > more clear if the old component is still required or not. > > Let us first complete the new component and get it fully tested and then > restart this discussion. > > Regards, > Hans > > On Tue, 2010-02-02 at 19:46 -0800, Scott Gray wrote: >> Okay so once I saw this I took the 5 minutes necessary to look at eBay's services and start thinking that this commit is a bad idea. >> Please correct me if any of the following is wrong: >> - When you originally brought this up, you described the problem as one of XML vs. API but I think what you actually meant is eBay SDK vs. using XML directly? >> - You mentioned that the API (SDK) provides additional functionality but it appears to me that it simply abstracts the use of raw SOAP or XML when interacting with the actual API? >> >> Based on this I'm not sure that we should have separate components but that the XML based component should just be moved to using the SDK (assuming there are only advantages and no disadvantages in doing so). Doing anything else will just result in twice as much code to maintain with both components doing the same thing (or worse yet, similar things but with huge differences in implementation from the user's perspective). Converting the existing XML integration to use the SDK will ensure that we have a single solution in place and that no functionality in the existing component is lost. >> >> Regards >> Scott >> >> HotWax Media >> http://www.hotwaxmedia.com >> >> On 2/02/2010, at 7:16 PM, [hidden email] wrote: >> >>> Author: hansbak >>> Date: Wed Feb 3 03:16:07 2010 >>> New Revision: 905876 >>> >>> URL: http://svn.apache.org/viewvc?rev=905876&view=rev >>> Log: >>> move the java api functions from the existing ebay component to the new ebaystore component: no functional changes >>> >> > -- > Antwebsystems.com: Quality OFBiz services for competitive rates > |
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
|
|
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
|
|
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
|
|
On 2/02/2010, at 11:43 PM, Hans Bakker wrote:
> Jacopo, > > what we need is a wiki page where people can announce activities and > plans. Not only from committers but also from contributors and perhaps > even users. > > I have proposed this before. That's what we use the dev list for though right? What would a wiki page have achieved that simple discussions on the mailing list wouldn't have? > > In this case we tried to extend the existing ebay component but found > out that the xml interface could never support the required functions as > we needed them. Please also remember that not all required functions > were known from the start. As I mentioned earlier, it is my understanding that the SDK is just a tool for using the XML or SOAP interfaces, so I'm interested to know what wasn't possible via the XML interface? Regards Scott > > Regards, > Hans > > > On Wed, 2010-02-03 at 08:30 +0100, Jacopo Cappellato wrote: >> Hi Hans, >> >> first of all, thank you for contributing this big amount of code. >> >> On Feb 3, 2010, at 5:05 AM, Hans Bakker wrote: >> >>> Hi Scott, >>> >>> I am also not sure if we need 2 components. That can only be decided by >>> the users of the original Ebay component isn't it? I do not know the >>> user requirements of the original ebay component. >>> >> >> Having two components with potentially overlapping features for the same integration in the official trunk will cause maintenance problems and confusion; I guess we will all agree on this. >> I am not asking you to redo your job, it is too late, but... can we agree that from now on, before implementing a new feature in the trunk (or, even worst, before adding a new component) we have to study and understand what already exists and do our best to enhance the existing stuff? >> >>> Now we moved the new functionality to a separate component it is getting >>> more clear if the old component is still required or not. >>> >> >> This is a pain, but we will do this, I can't see another solution now, as soon as you have completed your work: instead of you studying the original ebay component we will have to study your new work and verify if the new component implements all the features covered by the old one and in the same way; if this will not be true... I don't know what we will do. >> >> Kind regards, >> >> Jacopo >> >> >>> Let us first complete the new component and get it fully tested and then >>> restart this discussion. >>> >>> Regards, >>> Hans >>> >>> On Tue, 2010-02-02 at 19:46 -0800, Scott Gray wrote: >>>> Okay so once I saw this I took the 5 minutes necessary to look at eBay's services and start thinking that this commit is a bad idea. >>>> Please correct me if any of the following is wrong: >>>> - When you originally brought this up, you described the problem as one of XML vs. API but I think what you actually meant is eBay SDK vs. using XML directly? >>>> - You mentioned that the API (SDK) provides additional functionality but it appears to me that it simply abstracts the use of raw SOAP or XML when interacting with the actual API? >>>> >>>> Based on this I'm not sure that we should have separate components but that the XML based component should just be moved to using the SDK (assuming there are only advantages and no disadvantages in doing so). Doing anything else will just result in twice as much code to maintain with both components doing the same thing (or worse yet, similar things but with huge differences in implementation from the user's perspective). Converting the existing XML integration to use the SDK will ensure that we have a single solution in place and that no functionality in the existing component is lost. >>>> >>>> Regards >>>> Scott >>>> >>>> HotWax Media >>>> http://www.hotwaxmedia.com >>>> >>>> On 2/02/2010, at 7:16 PM, [hidden email] wrote: >>>> >>>>> Author: hansbak >>>>> Date: Wed Feb 3 03:16:07 2010 >>>>> New Revision: 905876 >>>>> >>>>> URL: http://svn.apache.org/viewvc?rev=905876&view=rev >>>>> Log: >>>>> move the java api functions from the existing ebay component to the new ebaystore component: no functional changes >>>>> >>>> >>> -- >>> Antwebsystems.com: Quality OFBiz services for competitive rates >>> >> > -- > Antwebsystems.com: Quality OFBiz services for competitive rates > |
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
|
|
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
|
|
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
|
|
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
|
|
Hi Hans,
Based on your recent commits I guess your considering this discussion over? Regards Scott On 3/02/2010, at 1:01 AM, Jacopo Cappellato wrote: > > On Feb 3, 2010, at 8:43 AM, Hans Bakker wrote: > >> Jacopo, >> >> what we need is a wiki page where people can announce activities and >> plans. Not only from committers but also from contributors and perhaps >> even users. >> >> I have proposed this before. >> > > I think we already have something similar: > > http://cwiki.apache.org/confluence/display/OFBADMIN/New+Features+Roadmap+-+Living+Document > >> In this case we tried to extend the existing ebay component but found >> out that the xml interface could never support the required functions as >> we needed them. > > This is not a good reason for stopping your research about supported features and building a new component. > The valid options I see are: > 1) adding *new* features to the original component using the different technology > 2) and enhancing the existing features, where needed, using the XML approach or > 3) reimplement the existing features in the original component with the new technology before enhancing them > > Jacopo > >> Please also remember that not all required functions >> were known from the start. >> >> Regards, >> Hans >> >> >> On Wed, 2010-02-03 at 08:30 +0100, Jacopo Cappellato wrote: >>> Hi Hans, >>> >>> first of all, thank you for contributing this big amount of code. >>> >>> On Feb 3, 2010, at 5:05 AM, Hans Bakker wrote: >>> >>>> Hi Scott, >>>> >>>> I am also not sure if we need 2 components. That can only be decided by >>>> the users of the original Ebay component isn't it? I do not know the >>>> user requirements of the original ebay component. >>>> >>> >>> Having two components with potentially overlapping features for the same integration in the official trunk will cause maintenance problems and confusion; I guess we will all agree on this. >>> I am not asking you to redo your job, it is too late, but... can we agree that from now on, before implementing a new feature in the trunk (or, even worst, before adding a new component) we have to study and understand what already exists and do our best to enhance the existing stuff? >>> >>>> Now we moved the new functionality to a separate component it is getting >>>> more clear if the old component is still required or not. >>>> >>> >>> This is a pain, but we will do this, I can't see another solution now, as soon as you have completed your work: instead of you studying the original ebay component we will have to study your new work and verify if the new component implements all the features covered by the old one and in the same way; if this will not be true... I don't know what we will do. >>> >>> Kind regards, >>> >>> Jacopo >>> >>> >>>> Let us first complete the new component and get it fully tested and then >>>> restart this discussion. >>>> >>>> Regards, >>>> Hans >>>> >>>> On Tue, 2010-02-02 at 19:46 -0800, Scott Gray wrote: >>>>> Okay so once I saw this I took the 5 minutes necessary to look at eBay's services and start thinking that this commit is a bad idea. >>>>> Please correct me if any of the following is wrong: >>>>> - When you originally brought this up, you described the problem as one of XML vs. API but I think what you actually meant is eBay SDK vs. using XML directly? >>>>> - You mentioned that the API (SDK) provides additional functionality but it appears to me that it simply abstracts the use of raw SOAP or XML when interacting with the actual API? >>>>> >>>>> Based on this I'm not sure that we should have separate components but that the XML based component should just be moved to using the SDK (assuming there are only advantages and no disadvantages in doing so). Doing anything else will just result in twice as much code to maintain with both components doing the same thing (or worse yet, similar things but with huge differences in implementation from the user's perspective). Converting the existing XML integration to use the SDK will ensure that we have a single solution in place and that no functionality in the existing component is lost. >>>>> >>>>> Regards >>>>> Scott >>>>> >>>>> HotWax Media >>>>> http://www.hotwaxmedia.com >>>>> >>>>> On 2/02/2010, at 7:16 PM, [hidden email] wrote: >>>>> >>>>>> Author: hansbak >>>>>> Date: Wed Feb 3 03:16:07 2010 >>>>>> New Revision: 905876 >>>>>> >>>>>> URL: http://svn.apache.org/viewvc?rev=905876&view=rev >>>>>> Log: >>>>>> move the java api functions from the existing ebay component to the new ebaystore component: no functional changes >>>>>> >>>>> >>>> -- >>>> Antwebsystems.com: Quality OFBiz services for competitive rates >>>> >>> >> -- >> Antwebsystems.com: Quality OFBiz services for competitive rates >> > |
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
|
|
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
|
|
In reply to this post by Scott Gray-2
On 3/02/2010, at 11:04 PM, Hans Bakker wrote:
> Hi Scott, > > I only wondering why you send this email, can you explain that to me? As I mentioned below, your commits indicated that you are continuing in your current direction which is something I disagree with, I was hoping some agreement could be reached through discussion. Was it in some way unreasonable to send the email? > Anyway, thanks for asking, i still think it is required. It showed with > the ebay component: > > 1. creators of the original component would have liked to discuss it. Maybe I missed them but what questions have you asked regarding the current implementation that someone could respond to? Regardless, once the code becomes part of the project there is no longer any requirement for the original developers to provide you with code support, and that lack of support doesn't necessarily give you a green light to create a duplicate component which will ultimately cause harm to the community. > 2. a non committer had already developed a component as we just did. Huh? How is that relevant? > so a lot of effort could have been saved here..... > > However if nobody wants it, sure i will give up. > > don't worry about that. It's not about not wanting your eBay contributions, it's about avoiding duplication in the project which will leave users confused and with additional analysis to do and I'm yet to see a good reason for this other than that it is easier for you. > > Regards, > Hans > > On Wed, 2010-02-03 at 22:40 -0800, Scott Gray wrote: >> Hi Hans, >> >> Based on your recent commits I guess your considering this discussion over? >> >> Regards >> Scott >> >> On 3/02/2010, at 1:01 AM, Jacopo Cappellato wrote: >> >>> >>> On Feb 3, 2010, at 8:43 AM, Hans Bakker wrote: >>> >>>> Jacopo, >>>> >>>> what we need is a wiki page where people can announce activities and >>>> plans. Not only from committers but also from contributors and perhaps >>>> even users. >>>> >>>> I have proposed this before. >>>> >>> >>> I think we already have something similar: >>> >>> http://cwiki.apache.org/confluence/display/OFBADMIN/New+Features+Roadmap+-+Living+Document >>> >>>> In this case we tried to extend the existing ebay component but found >>>> out that the xml interface could never support the required functions as >>>> we needed them. >>> >>> This is not a good reason for stopping your research about supported features and building a new component. >>> The valid options I see are: >>> 1) adding *new* features to the original component using the different technology >>> 2) and enhancing the existing features, where needed, using the XML approach or >>> 3) reimplement the existing features in the original component with the new technology before enhancing them >>> >>> Jacopo >>> >>>> Please also remember that not all required functions >>>> were known from the start. >>>> >>>> Regards, >>>> Hans >>>> >>>> >>>> On Wed, 2010-02-03 at 08:30 +0100, Jacopo Cappellato wrote: >>>>> Hi Hans, >>>>> >>>>> first of all, thank you for contributing this big amount of code. >>>>> >>>>> On Feb 3, 2010, at 5:05 AM, Hans Bakker wrote: >>>>> >>>>>> Hi Scott, >>>>>> >>>>>> I am also not sure if we need 2 components. That can only be decided by >>>>>> the users of the original Ebay component isn't it? I do not know the >>>>>> user requirements of the original ebay component. >>>>>> >>>>> >>>>> Having two components with potentially overlapping features for the same integration in the official trunk will cause maintenance problems and confusion; I guess we will all agree on this. >>>>> I am not asking you to redo your job, it is too late, but... can we agree that from now on, before implementing a new feature in the trunk (or, even worst, before adding a new component) we have to study and understand what already exists and do our best to enhance the existing stuff? >>>>> >>>>>> Now we moved the new functionality to a separate component it is getting >>>>>> more clear if the old component is still required or not. >>>>>> >>>>> >>>>> This is a pain, but we will do this, I can't see another solution now, as soon as you have completed your work: instead of you studying the original ebay component we will have to study your new work and verify if the new component implements all the features covered by the old one and in the same way; if this will not be true... I don't know what we will do. >>>>> >>>>> Kind regards, >>>>> >>>>> Jacopo >>>>> >>>>> >>>>>> Let us first complete the new component and get it fully tested and then >>>>>> restart this discussion. >>>>>> >>>>>> Regards, >>>>>> Hans >>>>>> >>>>>> On Tue, 2010-02-02 at 19:46 -0800, Scott Gray wrote: >>>>>>> Okay so once I saw this I took the 5 minutes necessary to look at eBay's services and start thinking that this commit is a bad idea. >>>>>>> Please correct me if any of the following is wrong: >>>>>>> - When you originally brought this up, you described the problem as one of XML vs. API but I think what you actually meant is eBay SDK vs. using XML directly? >>>>>>> - You mentioned that the API (SDK) provides additional functionality but it appears to me that it simply abstracts the use of raw SOAP or XML when interacting with the actual API? >>>>>>> >>>>>>> Based on this I'm not sure that we should have separate components but that the XML based component should just be moved to using the SDK (assuming there are only advantages and no disadvantages in doing so). Doing anything else will just result in twice as much code to maintain with both components doing the same thing (or worse yet, similar things but with huge differences in implementation from the user's perspective). Converting the existing XML integration to use the SDK will ensure that we have a single solution in place and that no functionality in the existing component is lost. >>>>>>> >>>>>>> Regards >>>>>>> Scott >>>>>>> >>>>>>> HotWax Media >>>>>>> http://www.hotwaxmedia.com >>>>>>> >>>>>>> On 2/02/2010, at 7:16 PM, [hidden email] wrote: >>>>>>> >>>>>>>> Author: hansbak >>>>>>>> Date: Wed Feb 3 03:16:07 2010 >>>>>>>> New Revision: 905876 >>>>>>>> >>>>>>>> URL: http://svn.apache.org/viewvc?rev=905876&view=rev >>>>>>>> Log: >>>>>>>> move the java api functions from the existing ebay component to the new ebaystore component: no functional changes >>>>>>>> >>>>>>> >>>>>> -- >>>>>> Antwebsystems.com: Quality OFBiz services for competitive rates >>>>>> >>>>> >>>> -- >>>> Antwebsystems.com: Quality OFBiz services for competitive rates >>>> >>> >> > -- > Antwebsystems.com: Quality OFBiz services for competitive rates > |
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
|
|
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
|
|
Haan,
I'm sorry to hear that, I guess if no one else feels strongly about this then I'll bow out and allow you to continue with your duplication of existing code. Regards Scott HotWax Media http://www.hotwaxmedia.com On 3/02/2010, at 11:52 PM, Hans Bakker wrote: > Scoot, > > i am sorry. As I mentioned in another email jacopo already saw that we > are too far down the road. I cannot change. Anybody with Ebay knowledge > would appreciate this contribution and replace the old ebay component > directly with the new one. > > I am sorry i am very busy here and cannot spend more time on this. > > Hans. > > p.s. my reaction was on my proposal to have a "work in progress list > added" irrelevant anyway. > > > On Wed, 2010-02-03 at 23:35 -0800, Scott Gray wrote: >> On 3/02/2010, at 11:04 PM, Hans Bakker wrote: >> >>> Hi Scott, >>> >>> I only wondering why you send this email, can you explain that to me? >> >> As I mentioned below, your commits indicated that you are continuing in your current direction which is something I disagree with, I was hoping some agreement could be reached through discussion. Was it in some way unreasonable to send the email? >> >>> Anyway, thanks for asking, i still think it is required. It showed with >>> the ebay component: >>> >>> 1. creators of the original component would have liked to discuss it. >> >> Maybe I missed them but what questions have you asked regarding the current implementation that someone could respond to? >> Regardless, once the code becomes part of the project there is no longer any requirement for the original developers to provide you with code support, and that lack of support doesn't necessarily give you a green light to create a duplicate component which will ultimately cause harm to the community. >> >>> 2. a non committer had already developed a component as we just did. >> >> Huh? How is that relevant? >> >>> so a lot of effort could have been saved here..... >>> >>> However if nobody wants it, sure i will give up. >>> >>> don't worry about that. >> >> It's not about not wanting your eBay contributions, it's about avoiding duplication in the project which will leave users confused and with additional analysis to do and I'm yet to see a good reason for this other than that it is easier for you. >> >>> >>> Regards, >>> Hans >>> >>> On Wed, 2010-02-03 at 22:40 -0800, Scott Gray wrote: >>>> Hi Hans, >>>> >>>> Based on your recent commits I guess your considering this discussion over? >>>> >>>> Regards >>>> Scott >>>> >>>> On 3/02/2010, at 1:01 AM, Jacopo Cappellato wrote: >>>> >>>>> >>>>> On Feb 3, 2010, at 8:43 AM, Hans Bakker wrote: >>>>> >>>>>> Jacopo, >>>>>> >>>>>> what we need is a wiki page where people can announce activities and >>>>>> plans. Not only from committers but also from contributors and perhaps >>>>>> even users. >>>>>> >>>>>> I have proposed this before. >>>>>> >>>>> >>>>> I think we already have something similar: >>>>> >>>>> http://cwiki.apache.org/confluence/display/OFBADMIN/New+Features+Roadmap+-+Living+Document >>>>> >>>>>> In this case we tried to extend the existing ebay component but found >>>>>> out that the xml interface could never support the required functions as >>>>>> we needed them. >>>>> >>>>> This is not a good reason for stopping your research about supported features and building a new component. >>>>> The valid options I see are: >>>>> 1) adding *new* features to the original component using the different technology >>>>> 2) and enhancing the existing features, where needed, using the XML approach or >>>>> 3) reimplement the existing features in the original component with the new technology before enhancing them >>>>> >>>>> Jacopo >>>>> >>>>>> Please also remember that not all required functions >>>>>> were known from the start. >>>>>> >>>>>> Regards, >>>>>> Hans >>>>>> >>>>>> >>>>>> On Wed, 2010-02-03 at 08:30 +0100, Jacopo Cappellato wrote: >>>>>>> Hi Hans, >>>>>>> >>>>>>> first of all, thank you for contributing this big amount of code. >>>>>>> >>>>>>> On Feb 3, 2010, at 5:05 AM, Hans Bakker wrote: >>>>>>> >>>>>>>> Hi Scott, >>>>>>>> >>>>>>>> I am also not sure if we need 2 components. That can only be decided by >>>>>>>> the users of the original Ebay component isn't it? I do not know the >>>>>>>> user requirements of the original ebay component. >>>>>>>> >>>>>>> >>>>>>> Having two components with potentially overlapping features for the same integration in the official trunk will cause maintenance problems and confusion; I guess we will all agree on this. >>>>>>> I am not asking you to redo your job, it is too late, but... can we agree that from now on, before implementing a new feature in the trunk (or, even worst, before adding a new component) we have to study and understand what already exists and do our best to enhance the existing stuff? >>>>>>> >>>>>>>> Now we moved the new functionality to a separate component it is getting >>>>>>>> more clear if the old component is still required or not. >>>>>>>> >>>>>>> >>>>>>> This is a pain, but we will do this, I can't see another solution now, as soon as you have completed your work: instead of you studying the original ebay component we will have to study your new work and verify if the new component implements all the features covered by the old one and in the same way; if this will not be true... I don't know what we will do. >>>>>>> >>>>>>> Kind regards, >>>>>>> >>>>>>> Jacopo >>>>>>> >>>>>>> >>>>>>>> Let us first complete the new component and get it fully tested and then >>>>>>>> restart this discussion. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Hans >>>>>>>> >>>>>>>> On Tue, 2010-02-02 at 19:46 -0800, Scott Gray wrote: >>>>>>>>> Okay so once I saw this I took the 5 minutes necessary to look at eBay's services and start thinking that this commit is a bad idea. >>>>>>>>> Please correct me if any of the following is wrong: >>>>>>>>> - When you originally brought this up, you described the problem as one of XML vs. API but I think what you actually meant is eBay SDK vs. using XML directly? >>>>>>>>> - You mentioned that the API (SDK) provides additional functionality but it appears to me that it simply abstracts the use of raw SOAP or XML when interacting with the actual API? >>>>>>>>> >>>>>>>>> Based on this I'm not sure that we should have separate components but that the XML based component should just be moved to using the SDK (assuming there are only advantages and no disadvantages in doing so). Doing anything else will just result in twice as much code to maintain with both components doing the same thing (or worse yet, similar things but with huge differences in implementation from the user's perspective). Converting the existing XML integration to use the SDK will ensure that we have a single solution in place and that no functionality in the existing component is lost. >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> Scott >>>>>>>>> >>>>>>>>> HotWax Media >>>>>>>>> http://www.hotwaxmedia.com >>>>>>>>> >>>>>>>>> On 2/02/2010, at 7:16 PM, [hidden email] wrote: >>>>>>>>> >>>>>>>>>> Author: hansbak >>>>>>>>>> Date: Wed Feb 3 03:16:07 2010 >>>>>>>>>> New Revision: 905876 >>>>>>>>>> >>>>>>>>>> URL: http://svn.apache.org/viewvc?rev=905876&view=rev >>>>>>>>>> Log: >>>>>>>>>> move the java api functions from the existing ebay component to the new ebaystore component: no functional changes >>>>>>>>>> >>>>>>>>> >>>>>>>> -- >>>>>>>> Antwebsystems.com: Quality OFBiz services for competitive rates >>>>>>>> >>>>>>> >>>>>> -- >>>>>> Antwebsystems.com: Quality OFBiz services for competitive rates >>>>>> >>>>> >>>> >>> -- >>> Antwebsystems.com: Quality OFBiz services for competitive rates >>> >> > -- > Antwebsystems.com: Quality OFBiz services for competitive rates > |
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
|
|
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
|
|
How can introducing another EBay implementation because a fellow committer is just too far down that road really ok for the rest of the project? Try explaining it to anyone trying to use the system why this was done - unfortunately we can't (don't know the original gap or what was solved by this new system) so we have basically forked the Ebay component because someone didn't want to do the proper analysis about even what they're getting with this new system.
It's just unfortunate. Fellow committer - again thanks for trying to push things forward - you do that that after and we all appreciate it, but if you weren't in such a hurry sometimes, we'd have more substantive conversation that would lead to a better software product for you, your customers and the rest of the community. Instead, we've not only got a new Ebay component, but everyone also gets additional analysis to on top of trying to figure out Ebay. Cheers, Ruppert On Feb 4, 2010, at 2:50 AM, Jacques Le Roux wrote: > I will try to have a look today, in order to introduce a 3d party in this discussion... > > Jacques > > From: "Scott Gray" <[hidden email]> > Haan, > > I'm sorry to hear that, I guess if no one else feels strongly about this then I'll bow out and allow you to continue with your > duplication of existing code. > > Regards > Scott > > HotWax Media > http://www.hotwaxmedia.com > > On 3/02/2010, at 11:52 PM, Hans Bakker wrote: > >> Scoot, >> >> i am sorry. As I mentioned in another email jacopo already saw that we >> are too far down the road. I cannot change. Anybody with Ebay knowledge >> would appreciate this contribution and replace the old ebay component >> directly with the new one. >> >> I am sorry i am very busy here and cannot spend more time on this. >> >> Hans. >> >> p.s. my reaction was on my proposal to have a "work in progress list >> added" irrelevant anyway. >> >> >> On Wed, 2010-02-03 at 23:35 -0800, Scott Gray wrote: >>> On 3/02/2010, at 11:04 PM, Hans Bakker wrote: >>> >>>> Hi Scott, >>>> >>>> I only wondering why you send this email, can you explain that to me? >>> >>> As I mentioned below, your commits indicated that you are continuing in your current direction which is something I disagree >>> with, I was hoping some agreement could be reached through discussion. Was it in some way unreasonable to send the email? >>> >>>> Anyway, thanks for asking, i still think it is required. It showed with >>>> the ebay component: >>>> >>>> 1. creators of the original component would have liked to discuss it. >>> >>> Maybe I missed them but what questions have you asked regarding the current implementation that someone could respond to? >>> Regardless, once the code becomes part of the project there is no longer any requirement for the original developers to provide >>> you with code support, and that lack of support doesn't necessarily give you a green light to create a duplicate component which >>> will ultimately cause harm to the community. >>> >>>> 2. a non committer had already developed a component as we just did. >>> >>> Huh? How is that relevant? >>> >>>> so a lot of effort could have been saved here..... >>>> >>>> However if nobody wants it, sure i will give up. >>>> >>>> don't worry about that. >>> >>> It's not about not wanting your eBay contributions, it's about avoiding duplication in the project which will leave users >>> confused and with additional analysis to do and I'm yet to see a good reason for this other than that it is easier for you. >>> >>>> >>>> Regards, >>>> Hans >>>> >>>> On Wed, 2010-02-03 at 22:40 -0800, Scott Gray wrote: >>>>> Hi Hans, >>>>> >>>>> Based on your recent commits I guess your considering this discussion over? >>>>> >>>>> Regards >>>>> Scott >>>>> >>>>> On 3/02/2010, at 1:01 AM, Jacopo Cappellato wrote: >>>>> >>>>>> >>>>>> On Feb 3, 2010, at 8:43 AM, Hans Bakker wrote: >>>>>> >>>>>>> Jacopo, >>>>>>> >>>>>>> what we need is a wiki page where people can announce activities and >>>>>>> plans. Not only from committers but also from contributors and perhaps >>>>>>> even users. >>>>>>> >>>>>>> I have proposed this before. >>>>>>> >>>>>> >>>>>> I think we already have something similar: >>>>>> >>>>>> http://cwiki.apache.org/confluence/display/OFBADMIN/New+Features+Roadmap+-+Living+Document >>>>>> >>>>>>> In this case we tried to extend the existing ebay component but found >>>>>>> out that the xml interface could never support the required functions as >>>>>>> we needed them. >>>>>> >>>>>> This is not a good reason for stopping your research about supported features and building a new component. >>>>>> The valid options I see are: >>>>>> 1) adding *new* features to the original component using the different technology >>>>>> 2) and enhancing the existing features, where needed, using the XML approach or >>>>>> 3) reimplement the existing features in the original component with the new technology before enhancing them >>>>>> >>>>>> Jacopo >>>>>> >>>>>>> Please also remember that not all required functions >>>>>>> were known from the start. >>>>>>> >>>>>>> Regards, >>>>>>> Hans >>>>>>> >>>>>>> >>>>>>> On Wed, 2010-02-03 at 08:30 +0100, Jacopo Cappellato wrote: >>>>>>>> Hi Hans, >>>>>>>> >>>>>>>> first of all, thank you for contributing this big amount of code. >>>>>>>> >>>>>>>> On Feb 3, 2010, at 5:05 AM, Hans Bakker wrote: >>>>>>>> >>>>>>>>> Hi Scott, >>>>>>>>> >>>>>>>>> I am also not sure if we need 2 components. That can only be decided by >>>>>>>>> the users of the original Ebay component isn't it? I do not know the >>>>>>>>> user requirements of the original ebay component. >>>>>>>>> >>>>>>>> >>>>>>>> Having two components with potentially overlapping features for the same integration in the official trunk will cause >>>>>>>> maintenance problems and confusion; I guess we will all agree on this. >>>>>>>> I am not asking you to redo your job, it is too late, but... can we agree that from now on, before implementing a new >>>>>>>> feature in the trunk (or, even worst, before adding a new component) we have to study and understand what already exists and >>>>>>>> do our best to enhance the existing stuff? >>>>>>>> >>>>>>>>> Now we moved the new functionality to a separate component it is getting >>>>>>>>> more clear if the old component is still required or not. >>>>>>>>> >>>>>>>> >>>>>>>> This is a pain, but we will do this, I can't see another solution now, as soon as you have completed your work: instead of >>>>>>>> you studying the original ebay component we will have to study your new work and verify if the new component implements all >>>>>>>> the features covered by the old one and in the same way; if this will not be true... I don't know what we will do. >>>>>>>> >>>>>>>> Kind regards, >>>>>>>> >>>>>>>> Jacopo >>>>>>>> >>>>>>>> >>>>>>>>> Let us first complete the new component and get it fully tested and then >>>>>>>>> restart this discussion. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Hans >>>>>>>>> >>>>>>>>> On Tue, 2010-02-02 at 19:46 -0800, Scott Gray wrote: >>>>>>>>>> Okay so once I saw this I took the 5 minutes necessary to look at eBay's services and start thinking that this commit is a >>>>>>>>>> bad idea. >>>>>>>>>> Please correct me if any of the following is wrong: >>>>>>>>>> - When you originally brought this up, you described the problem as one of XML vs. API but I think what you actually meant >>>>>>>>>> is eBay SDK vs. using XML directly? >>>>>>>>>> - You mentioned that the API (SDK) provides additional functionality but it appears to me that it simply abstracts the use >>>>>>>>>> of raw SOAP or XML when interacting with the actual API? >>>>>>>>>> >>>>>>>>>> Based on this I'm not sure that we should have separate components but that the XML based component should just be moved >>>>>>>>>> to using the SDK (assuming there are only advantages and no disadvantages in doing so). Doing anything else will just >>>>>>>>>> result in twice as much code to maintain with both components doing the same thing (or worse yet, similar things but with >>>>>>>>>> huge differences in implementation from the user's perspective). Converting the existing XML integration to use the SDK >>>>>>>>>> will ensure that we have a single solution in place and that no functionality in the existing component is lost. >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> Scott >>>>>>>>>> >>>>>>>>>> HotWax Media >>>>>>>>>> http://www.hotwaxmedia.com >>>>>>>>>> >>>>>>>>>> On 2/02/2010, at 7:16 PM, [hidden email] wrote: >>>>>>>>>> >>>>>>>>>>> Author: hansbak >>>>>>>>>>> Date: Wed Feb 3 03:16:07 2010 >>>>>>>>>>> New Revision: 905876 >>>>>>>>>>> >>>>>>>>>>> URL: http://svn.apache.org/viewvc?rev=905876&view=rev >>>>>>>>>>> Log: >>>>>>>>>>> move the java api functions from the existing ebay component to the new ebaystore component: no functional changes >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> -- >>>>>>>>> Antwebsystems.com: Quality OFBiz services for competitive rates >>>>>>>>> >>>>>>>> >>>>>>> -- >>>>>>> Antwebsystems.com: Quality OFBiz services for competitive rates >>>>>>> >>>>>> >>>>> >>>> -- >>>> Antwebsystems.com: Quality OFBiz services for competitive rates >>>> >>> >> -- >> Antwebsystems.com: Quality OFBiz services for competitive rates >> > > |
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
|
|
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
|
|
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
|
|
In reply to this post by samhamilton
On 4/02/2010, at 10:58 PM, Sam Hamilton wrote:
> Couple of things > > 1. calling one ebay and one ebaystore is confusing when browsing the > source tree - perhaps once we know what the difference is between them > call them that? If its correct - call one eBay-XML and the other > eBay-API for example. One uses direct XML and the other is using eBay's SDK to do the heavy lifting. They both use the same API and the use of the SDK is mostly just a excuse for implementing the same thing in a different way. > > 2. eBay has a huge amount of developer documentation once we know what > the difference is how about putting a README file in the folder of each > pointing to the eBay docs showing what each component is capable of > achieving? http://developer.ebay.com/ Both have the potential to achieve the same goals but it is likely they will just end up taking two different approaches to achieve the same thing. Hans may document his component but the other component will likely remain as is (it may have some documentation, I don't know). Either way, the need to document (and continue to document as the components change) the differences between the two is just additional effort required by the community for no good reason, or at least I'm yet to hear a good reason other than "sorry I'm in a hurry". > 3. If the ebaystore module does everything that the ebay module > currently does then why is getting rid of ebay module a bad thing? There is no guarantee (and it seems pretty unlikely) that the ebaystore will do everything that the ebay module does, while they may achieve the same goals the differences from the user's perspective will likely be quite large. The main reason for the new implementation is that Hans doesn't understand the existing one and found it easier to just start fresh. All we're really ending up with here is a stack of duplication and additional analysis effort with no benefit. > > Sam > > > On 05/02/2010 12:42, Tim Ruppert wrote: >> How can introducing another EBay implementation because a fellow committer is just too far down that road really ok for the rest of the project? Try explaining it to anyone trying to use the system why this was done - unfortunately we can't (don't know the original gap or what was solved by this new system) so we have basically forked the Ebay component because someone didn't want to do the proper analysis about even what they're getting with this new system. >> >> It's just unfortunate. Fellow committer - again thanks for trying to push things forward - you do that that after and we all appreciate it, but if you weren't in such a hurry sometimes, we'd have more substantive conversation that would lead to a better software product for you, your customers and the rest of the community. Instead, we've not only got a new Ebay component, but everyone also gets additional analysis to on top of trying to figure out Ebay. >> >> Cheers, >> Ruppert >> >> On Feb 4, 2010, at 2:50 AM, Jacques Le Roux wrote: >> >>> I will try to have a look today, in order to introduce a 3d party in this discussion... >>> >>> Jacques >>> >>> From: "Scott Gray" <[hidden email]> >>> Haan, >>> >>> I'm sorry to hear that, I guess if no one else feels strongly about this then I'll bow out and allow you to continue with your >>> duplication of existing code. >>> >>> Regards >>> Scott >>> >>> HotWax Media >>> http://www.hotwaxmedia.com >>> >>> On 3/02/2010, at 11:52 PM, Hans Bakker wrote: >>> >>>> Scoot, >>>> >>>> i am sorry. As I mentioned in another email jacopo already saw that we >>>> are too far down the road. I cannot change. Anybody with Ebay knowledge >>>> would appreciate this contribution and replace the old ebay component >>>> directly with the new one. >>>> >>>> I am sorry i am very busy here and cannot spend more time on this. >>>> >>>> Hans. >>>> >>>> p.s. my reaction was on my proposal to have a "work in progress list >>>> added" irrelevant anyway. >>>> >>>> >>>> On Wed, 2010-02-03 at 23:35 -0800, Scott Gray wrote: >>>>> On 3/02/2010, at 11:04 PM, Hans Bakker wrote: >>>>> >>>>>> Hi Scott, >>>>>> >>>>>> I only wondering why you send this email, can you explain that to me? >>>>> >>>>> As I mentioned below, your commits indicated that you are continuing in your current direction which is something I disagree >>>>> with, I was hoping some agreement could be reached through discussion. Was it in some way unreasonable to send the email? >>>>> >>>>>> Anyway, thanks for asking, i still think it is required. It showed with >>>>>> the ebay component: >>>>>> >>>>>> 1. creators of the original component would have liked to discuss it. >>>>> >>>>> Maybe I missed them but what questions have you asked regarding the current implementation that someone could respond to? >>>>> Regardless, once the code becomes part of the project there is no longer any requirement for the original developers to provide >>>>> you with code support, and that lack of support doesn't necessarily give you a green light to create a duplicate component which >>>>> will ultimately cause harm to the community. >>>>> >>>>>> 2. a non committer had already developed a component as we just did. >>>>> >>>>> Huh? How is that relevant? >>>>> >>>>>> so a lot of effort could have been saved here..... >>>>>> >>>>>> However if nobody wants it, sure i will give up. >>>>>> >>>>>> don't worry about that. >>>>> >>>>> It's not about not wanting your eBay contributions, it's about avoiding duplication in the project which will leave users >>>>> confused and with additional analysis to do and I'm yet to see a good reason for this other than that it is easier for you. >>>>> >>>>>> >>>>>> Regards, >>>>>> Hans >>>>>> >>>>>> On Wed, 2010-02-03 at 22:40 -0800, Scott Gray wrote: >>>>>>> Hi Hans, >>>>>>> >>>>>>> Based on your recent commits I guess your considering this discussion over? >>>>>>> >>>>>>> Regards >>>>>>> Scott >>>>>>> >>>>>>> On 3/02/2010, at 1:01 AM, Jacopo Cappellato wrote: >>>>>>> >>>>>>>> >>>>>>>> On Feb 3, 2010, at 8:43 AM, Hans Bakker wrote: >>>>>>>> >>>>>>>>> Jacopo, >>>>>>>>> >>>>>>>>> what we need is a wiki page where people can announce activities and >>>>>>>>> plans. Not only from committers but also from contributors and perhaps >>>>>>>>> even users. >>>>>>>>> >>>>>>>>> I have proposed this before. >>>>>>>>> >>>>>>>> >>>>>>>> I think we already have something similar: >>>>>>>> >>>>>>>> http://cwiki.apache.org/confluence/display/OFBADMIN/New+Features+Roadmap+-+Living+Document >>>>>>>> >>>>>>>>> In this case we tried to extend the existing ebay component but found >>>>>>>>> out that the xml interface could never support the required functions as >>>>>>>>> we needed them. >>>>>>>> >>>>>>>> This is not a good reason for stopping your research about supported features and building a new component. >>>>>>>> The valid options I see are: >>>>>>>> 1) adding *new* features to the original component using the different technology >>>>>>>> 2) and enhancing the existing features, where needed, using the XML approach or >>>>>>>> 3) reimplement the existing features in the original component with the new technology before enhancing them >>>>>>>> >>>>>>>> Jacopo >>>>>>>> >>>>>>>>> Please also remember that not all required functions >>>>>>>>> were known from the start. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Hans >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, 2010-02-03 at 08:30 +0100, Jacopo Cappellato wrote: >>>>>>>>>> Hi Hans, >>>>>>>>>> >>>>>>>>>> first of all, thank you for contributing this big amount of code. >>>>>>>>>> >>>>>>>>>> On Feb 3, 2010, at 5:05 AM, Hans Bakker wrote: >>>>>>>>>> >>>>>>>>>>> Hi Scott, >>>>>>>>>>> >>>>>>>>>>> I am also not sure if we need 2 components. That can only be decided by >>>>>>>>>>> the users of the original Ebay component isn't it? I do not know the >>>>>>>>>>> user requirements of the original ebay component. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Having two components with potentially overlapping features for the same integration in the official trunk will cause >>>>>>>>>> maintenance problems and confusion; I guess we will all agree on this. >>>>>>>>>> I am not asking you to redo your job, it is too late, but... can we agree that from now on, before implementing a new >>>>>>>>>> feature in the trunk (or, even worst, before adding a new component) we have to study and understand what already exists and >>>>>>>>>> do our best to enhance the existing stuff? >>>>>>>>>> >>>>>>>>>>> Now we moved the new functionality to a separate component it is getting >>>>>>>>>>> more clear if the old component is still required or not. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> This is a pain, but we will do this, I can't see another solution now, as soon as you have completed your work: instead of >>>>>>>>>> you studying the original ebay component we will have to study your new work and verify if the new component implements all >>>>>>>>>> the features covered by the old one and in the same way; if this will not be true... I don't know what we will do. >>>>>>>>>> >>>>>>>>>> Kind regards, >>>>>>>>>> >>>>>>>>>> Jacopo >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Let us first complete the new component and get it fully tested and then >>>>>>>>>>> restart this discussion. >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> Hans >>>>>>>>>>> >>>>>>>>>>> On Tue, 2010-02-02 at 19:46 -0800, Scott Gray wrote: >>>>>>>>>>>> Okay so once I saw this I took the 5 minutes necessary to look at eBay's services and start thinking that this commit is a >>>>>>>>>>>> bad idea. >>>>>>>>>>>> Please correct me if any of the following is wrong: >>>>>>>>>>>> - When you originally brought this up, you described the problem as one of XML vs. API but I think what you actually meant >>>>>>>>>>>> is eBay SDK vs. using XML directly? >>>>>>>>>>>> - You mentioned that the API (SDK) provides additional functionality but it appears to me that it simply abstracts the use >>>>>>>>>>>> of raw SOAP or XML when interacting with the actual API? >>>>>>>>>>>> >>>>>>>>>>>> Based on this I'm not sure that we should have separate components but that the XML based component should just be moved >>>>>>>>>>>> to using the SDK (assuming there are only advantages and no disadvantages in doing so). Doing anything else will just >>>>>>>>>>>> result in twice as much code to maintain with both components doing the same thing (or worse yet, similar things but with >>>>>>>>>>>> huge differences in implementation from the user's perspective). Converting the existing XML integration to use the SDK >>>>>>>>>>>> will ensure that we have a single solution in place and that no functionality in the existing component is lost. >>>>>>>>>>>> >>>>>>>>>>>> Regards >>>>>>>>>>>> Scott >>>>>>>>>>>> >>>>>>>>>>>> HotWax Media >>>>>>>>>>>> http://www.hotwaxmedia.com >>>>>>>>>>>> >>>>>>>>>>>> On 2/02/2010, at 7:16 PM, [hidden email] wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Author: hansbak >>>>>>>>>>>>> Date: Wed Feb 3 03:16:07 2010 >>>>>>>>>>>>> New Revision: 905876 >>>>>>>>>>>>> >>>>>>>>>>>>> URL: http://svn.apache.org/viewvc?rev=905876&view=rev >>>>>>>>>>>>> Log: >>>>>>>>>>>>> move the java api functions from the existing ebay component to the new ebaystore component: no functional changes >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Antwebsystems.com: Quality OFBiz services for competitive rates >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> -- >>>>>>>>> Antwebsystems.com: Quality OFBiz services for competitive rates >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> -- >>>>>> Antwebsystems.com: Quality OFBiz services for competitive rates >>>>>> >>>>> >>>> -- >>>> Antwebsystems.com: Quality OFBiz services for competitive rates >>>> >>> >>> >> > |
Re: svn commit: r905876 [1/7] - in /ofbiz/trunk: applications/commonext/documen
|
|
| Free forum by Nabble | Edit this page |