Responding to this message - per Jacopo and David's request. Hopefully this gets us back to discussing how we can go about fixing the ambiguity that has been introduced and will push us to a consolidated front on these features:
--- My recommendation - even at this point - is that we start to have a discussion about all of the things this new component does, and the people who are using the old one can put all of their feature coverage on the table - then we can discuss how to bring them together. This may be one ebay component which utilizes both XML for some things and the SDK for others - but without knowing the feature coverage - we're screwed. In this case - it matters very little to anyone what the technology choice ends up being - it's all about: 1. Making it easier for everyone who downloads OFBiz to know what to do with eBay -- These multi channels sales are more and more important each day in this economy. 2. Consolidating so that next time the SDK adds something that the XML does not, we can make good decisions about how to achieve the new features. Let's have this conversation - Hans, if you can provide a quick outline of what is being supported by all the functions that are newly implemented - this should be easy since the development was just done. Then maybe Marco, Ashish and Jacopo - people who helped build the current ebay component - can put the features out on the table for comparison as well. Once we have that, we can easily do the necessary gap analysis and discussion about what technologies support what, etc, etc. it could be that XML supports everything that we want and this new SDK becomes something that we might want to remove - or that this new implementation is the way to go and remove the old one - or even some hybrid of the two - but we won't know until we understand first what we need it to do, then what it can do currently, and come together on how to do it. Cheers, Ruppert On Feb 4, 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. > > 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/ > > 3. If the ebaystore module does everything that the ebay module > currently does then why is getting rid of ebay module a bad thing? > > 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" <scott.g...@hotwaxmedia.com> >>> 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, hans...@apache.org 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 >>>> >>> >>> >> >
smime.p7s
Description: S/MIME cryptographic signature
